Dlaczego "log and throw" jest uważany za anty-wzór? [zamknięte]
To pytanie wywołało dyskusję wokół tego artykułu, w którym nie otrzymałem żadnych dobrych odpowiedzi.
Dlaczego rejestrowanie wyjątku, a następnie ponowne jego przeglądanie (oczywiście zachowując oryginalny ślad stosu) jest złym pomysłem, jeśli nie możesz sobie z nim poradzić w inny sposób?
4 answers
Zakładam, że odpowiedź jest w dużej mierze dlatego, że dlaczego łapiesz go, jeśli nie możesz sobie z tym poradzić? Dlaczego nie pozwolić, aby ktokolwiek mógł sobie z tym poradzić (lub ktokolwiek pozostaje bez wyboru, jak tylko sobie z tym poradzić), zalogował się, jeśli uważa, że jest to godne dziennika?
Jeśli go złapiesz, zalogujesz i przerobisz, to nie ma możliwości, aby kod źródłowy wiedział, że już zalogowałeś wyjątek, więc ten sam wyjątek może zostać zarejestrowany dwa razy. Lub co gorsza, jeśli cały kod wyjściowy podąża za tym samym wzorcem, wyjątek może być rejestrowany dowolną liczbę razy, raz dla każdego poziomu w kodzie, który zdecyduje się go złapać, zalogować, a następnie rzucić go ponownie.
Niektórzy mogą również twierdzić, że ponieważ wyrzucanie i łapanie wyjątków jest stosunkowo kosztownymi operacjami, całe to łapanie i ponowne przeszukiwanie nie pomaga w wydajności środowiska uruchomieniowego. Nie pomaga to również Twojemu kodowi pod względem zwięzłości lub konserwacji.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-07-10 08:20:40
Log-and-throw jest dobrym wzorcem, jeśli jednostka łapie i zmienia wyjątek ma powody sądzić, że zawiera informacje, które nie będą rejestrowane dalej na stosie połączeń-przynajmniej nie w najbardziej pożądany sposób. Może to wystąpić z kilku powodów:
- wyjątek może być przechwycony i przetransferowany na granicy warstwy aplikacji i może zawierać informacje uprzywilejowane. Źle byłoby, gdyby warstwa bazy danych zezwalała na wyjątek, np. " próba dodania zduplikuj klucz "fnord" do pola "users", aby dotrzeć do zewnętrznej warstwy aplikacji( co z kolei może narazić ją na użytkownika), ale może być przydatne dla wewnętrznych części bazy danych, aby rzucić taki wyjątek, a interfejs aplikacji, aby go złapać, zalogować go bezpiecznie i rethrow nieco mniej opisowy wyjątek.
- wyjątek może być taki, który warstwa zewnętrzna prawdopodobnie spodziewa się obsłużyć bez logowania, ale warstwa wewnętrzna może wiedzieć coś, czego warstwa zewnętrzna nie wie co sugerowałoby, że logowanie może być przydatne. Jako prymitywny przykład, środkowa warstwa aplikacji może być zaprogramowana tak, aby spróbować połączyć się z jednym serwerem, a jeśli to nie zadziała, spróbuj z innym. Zalewanie dziennika aplikacji komunikatami "connection failed", gdy serwer jest wyłączony do konserwacji, może nie być pomocne, zwłaszcza, że -- z perspektywy aplikacji, wszystko działało dobrze. Przydatne może być przekazanie informacji o niepowodzeniu połączenia do zasobu rejestrującego powiązanego z serwerami, które mogą następnie filtrować logi tak, aby stworzyć raport, kiedy serwer poszedł w górę iw dół, w przeciwieństwie do dziennika każdej pojedynczej próby połączenia.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-07-11 15:44:49
Myślę, że najprostszym powodem jest to, że zazwyczaj masz jeden najwyższego poziomu obsługi robi to za ciebie, więc nie ma potrzeby zanieczyszczać kodu z tą obsługą WYJĄTKÓW.
Przekrojowy argument dotyczy w zasadzie tego, że jest to strata czasu na obsługę błędów, które cię nie dotyczą. O wiele lepiej pozwolić, aby błąd bańki w górę stosu wywołań, dopóki nie zostanie znaleziony odpowiedni handler.
Moim zdaniem jedyny raz kiedy można złapać wyjątek to kiedy można zrobić coś przydatnego z wynikami. Łapanie po prostu do logowania nie jest przydatne, ponieważ można scentralizować tę pracę dalej.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-07-10 08:20:08
IMO log and throw to ewidentne naruszenie zasady najmniejszego zaskoczenia.
Jeśli wyjątek jest prawidłowo obsługiwany dalej w stosie wywołań, może nie być wart wpisywania dziennika błędów. A potem jest mylące, aby znaleźć wpis dziennika błędów.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2013-08-14 07:26:24