Czy obsługa wyjątków ma charakter przekrojowy?


13

Nie widzę dużej różnicy między obawami związanymi z obsługą wyjątków i logowaniem, że oba są problemami przekrojowymi. Co myślisz? Czy nie powinien być traktowany osobno, zamiast przeplatać się z podstawową logiką, którą implementuje metoda?

EDYCJA : Próbuję powiedzieć, że moim zdaniem implementacja metody powinna zawierać tylko logikę udanej ścieżki wykonania, a wyjątki powinny być obsługiwane gdzie indziej. Nie chodzi o sprawdzone / niezaznaczone wyjątki.

Na przykład język może obsługiwać wyjątki w sposób w pełni sprawdzony przy użyciu takich konstrukcji:

class FileReader {

  public String readFile(String path) {
    // implement the reading logic, avoid exception handling
  }

}

handler FileReader {

   handle String readFile(String path) {
      when (IOException joe) {
        // somehow access the FileInputStram and close it
      }
   }

}

W powyższym języku koncepcyjnym program nie będzie się kompilował przy braku modułu FileReader obsługi , ponieważ readFile FileReader klasy nie zgłasza wyjątku. Deklarując FileReader moduł obsługi , kompilator może zapewnić, że jest on obsługiwany, a następnie program się skompiluje.

W ten sposób mamy najlepsze z sprawdzonych i niezaznaczonych problemów wyjątków: niezawodność i czytelność.

Odpowiedzi:


14

W niektórych przypadkach tak

W przypadkach, w których masz wyjątek, który chcesz zarejestrować (co, jak sądzę, prawie zawsze), wówczas tak jest związany z zagadnieniem przekrojowym.

Przez większość czasu nie

Weźmy jednak przykład SocketListener, jeśli program nasłuchujący gniazd zgłasza wyjątek ze względu na zerwanie połączenia przez drugi koniec, należy to przewidzieć, więc aplikacja powinna działać zgodnie z okolicznościami, które spowodowały wyjątek. Nie jest to coś, z czym powinien sobie poradzić ogólny aspekt, a zatem nie powinno to dotyczyć kwestii przekrojowych.

Określenie problemu przekrojowego

Jeśli duplikujesz ten sam kod w kółko, należy go wyodrębnić. Jeśli abstrakcja przejdzie na wiele warstw, może to być problem przekrojowy. Tylko wtedy należy to rozważyć.


4

Logowanie jest opcjonalne. Obsługa wyjątków nie jest.

Rejestrowanie jest dość ogólne i chociaż czerpie z określonej logiki, przekazuje je do ogólnego konsumenta. Wyjątki są zawsze specyficzne dla logiki, a część kodu znającego tę logikę musi poradzić sobie z bałaganem, który popełniła.

Przynajmniej w moim ograniczonym użyciu tych dwóch oznacza to, że te dwa cele najlepiej realizować na różne sposoby, a nie pod tym samym parasolem projektowym.


1

Uważam obsługę wyjątków za przekrojową kwestię dotyczącą niektórych rodzajów wyjątków. Istnieją lokalne wyjątki, które tylko kod bezpośredniego wywołania może poprawnie obsłużyć. Przykładem może być wyjątek bazy danych podczas próby wykonania zapytania. Ale są też wyjątki, które można i należy traktować bardziej globalnie. Przykładem może być wyjątek związany z brakiem poświadczeń bezpieczeństwa (zmusza użytkownika do ponownego zalogowania się). Lub przynajmniej potrzebujesz globalnego modułu obsługi na wypadek, gdyby wyjątek prześlizgnął się przez bardziej szczegółowy kod, aby wyjaśnić użytkownikowi, co powinien zrobić, aby zrestartować lub wysłać dziennik do działu IT lub coś w tym rodzaju. W przypadku tego rodzaju wyjątków obsługiwanych na całym świecie jest to problem przekrojowy.


0

Myślę, że wiąże się to z problemem nieszczelnych abstrakcji.

Wiele wyjątków powinno być wychwytywanych i ponownie wprowadzanych, gdy propagują one warstwy abstrakcji. Ponowne rzucanie powinno wyrzucić wyjątek w nowej formie, stosownie do abstrakcji, która wykonuje ponowne rzucanie, aby miało to sens jako część interfejsu. Innymi słowy, wyjątki od niższych poziomów abstrakcji powinny zostać przetłumaczone na formę abstrakcyjno-prądową, aby wyższe poziomy abstrakcji nie musiały wiedzieć o niższych poziomach, nawet wyłącznie w celu obsługi wyjątków.

Problemem jest jednak „zasada nieszczelnych abstrakcji”. Niektórych wyjątków nie można przetłumaczyć na formę, która ma sens w następnej warstwie abstrakcji.

Wyjątek związany z sieciowym systemem plików to prosty przykład. Awaria sieci nie może być wyrażona w kategoriach, które mają sens dla abstrakcji „pliku” lub, jeśli tak się dzieje, ta abstrakcja nie w pełni wyodrębniła wszystkich szczegółów związanych z implementacją obsługi plików.

Awaria sieci wyciekłaby zatem z podstawowej abstrakcji sieci i dlatego musi stanowić problem przekrojowy w pozostałej części kodu.

Nie dotyczy to jednak wyjątków. Wszystkie kody błędów zwracanych wartości dla interfejsów API plików, które tak naprawdę nie są powiązane z abstrakcją pliku, ale szczegółowo opisują dysk twardy lub sieć lub jakiekolwiek inne awarie są tym samym w innej formie, co oznacza, że ​​awarie dysku twardego i awarie sieci itd. są problemami przekrojowymi, niezależnie od sposobu zgłaszania tych awarii.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.