Dlaczego „loguj i rzucaj” jest uważane za anty-wzór? [Zamknięte]

To pytanie wywołała dyskusja wokół tego artykułu , w której nie otrzymałem żadnych dobrych odpowiedzi.

Dlaczego rejestrowanie wyjątku, a następnie ponowne jego zgłoszenie (oczywiście z zachowaniem oryginalnego śladu stosu) powinno być złym pomysłem, jeśli nie możesz sobie z tym poradzić w inny sposób?

Zakładam, że odpowiedź brzmi głównie dlatego, że dlaczego to łapiesz, jeśli nie możesz sobie z tym poradzić? Dlaczego nie pozwolić, aby ktokolwiek mógł sobie z tym poradzić (lub komukolwiek, kto nie ma innego wyboru, jak tylko zająć się tym), zarejestrował to, jeśli czuje, że jest to warte kłódki?

Jeśli go złapiesz, zarejestrujesz i wyrzucisz ponownie, kod nadrzędny nie będzie wiedział, że wyjątek został już zarejestrowany, więc ten sam wyjątek może zostać zarejestrowany dwukrotnie. Lub, co gorsza, jeśli cały nadrzędny kod jest zgodny z tym samym wzorcem, wyjątek może zostać zarejestrowany dowolną liczbę razy, raz dla każdego poziomu w kodzie, który zdecyduje się go złapać, zarejestrować, a następnie ponownie wyrzucić.

Niektórzy mogą również twierdzić, że skoro wyrzucanie i przechwytywanie wyjątków jest operacjami stosunkowo kosztownymi, całe to przechwytywanie i ponowne wrzucanie nie poprawia wydajności środowiska wykonawczego. Nie pomaga też twojemu kodowi pod względem zwięzłości lub łatwości utrzymania.

Log-and-throw to dobry wzorzec, jeśli jednostka przechwytująca i ponownie zgłaszająca wyjątek ma powód, by sądzić, że zawiera informacje, które nie zostaną zarejestrowane wyżej na stosie wywołań - przynajmniej nie w najbardziej pożądany sposób. Może się tak zdarzyć z kilku powodów:

1. Wyjątek może zostać przechwycony i ponownie zgłoszony na granicy warstwy aplikacji i może zawierać uprzywilejowane informacje. Byłoby źle, gdyby warstwa bazy danych zezwalała na wyjątek mówiący, np. „Próba dodania zduplikowanego klucza 'fnord' do pola 'użytkowników'”, aby dotrzeć do zewnętrznej warstwy aplikacji (co z kolei może ujawnić ją użytkownikowi), ale może być przydatne dla wewnętrznych części bazy danych, aby zgłosić taki wyjątek, a interfejs aplikacji, aby go przechwycić, bezpiecznie zarejestrować i ponownie zgłosić nieco mniej opisowy wyjątek.
2. Wyjątkiem może być taki, który warstwa zewnętrzna prawdopodobnie spodziewałaby się obsługi bez logowania, ale warstwa wewnętrzna może wiedzieć coś, czego warstwa zewnętrzna nie wie, co sugerowałoby, że rejestrowanie może być przydatne. Jako prymitywny przykład, środkowa warstwa aplikacji może być zaprogramowana tak, aby próbowała połączyć się z jednym serwerem, a jeśli to nie zadziała, spróbuj innego. Zapełnianie dziennika aplikacji komunikatami o niepowodzeniu połączenia, gdy serwer jest wyłączony z powodu konserwacji, może nie być pomocne, zwłaszcza że - z punktu widzenia aplikacji, wszystko działało dobrze. Przydatne może być przekazanie informacji o niepowodzeniu połączenia do zasobu rejestrującego skojarzonego z serwerami, który mógłby następnie filtrować dzienniki, aby wygenerować raport o błędach serwera, w przeciwieństwie do dziennika każdej pojedynczej próby połączenia .

Wydaje mi się, że najprostszym powodem jest to, że zazwyczaj masz jeden program obsługi najwyższego poziomu, który robi to za Ciebie, więc nie ma potrzeby zanieczyszczania kodu tą obsługą wyjątków.

Argument dotyczący przekrojowych obaw jest taki, że jest to strata czasu na obsługę błędów, które Cię nie dotyczą. Znacznie lepiej jest pozwolić, aby błąd wypełnił stos wywołań, dopóki nie zostanie znaleziony odpowiedni program obsługi.

Moim zdaniem jedyny przypadek, w którym powinieneś złapać wyjątek, to kiedy możesz zrobić coś pożytecznego z wynikami. Łapanie po prostu w celu zarejestrowania nie jest przydatne, ponieważ można by scentralizować tę pracę dalej.

Dziennik i rzut IMO stanowią wyraźne naruszenie zasady najmniejszej niespodzianki.

Jeśli wyjątek jest obsługiwany prawidłowo na wyższych poziomach stosu wywołań, wpis w dzienniku błędów może w ogóle nie być wart. A potem mylące jest znalezienie wpisu w dzienniku błędów.