Używanie wyjątków w kodzie biznesowym.

Przy okazji pisania kodu w ten weekend naszła mnie refleksja na temat używania wyjątków.

Pytanie: Jak należy wykorzystywać wyjątki podczas pisania kod biznesowego?

Otóż, NIE NALEŻY!

Tyle w uproszczeniu. Chodzi o to, że rzucanie wyjątkami w kodzie biznesowym jest niewałaściwe. Oznacza to że programista nie przemyślał działania kodu biznesowego i godzi się na nieprzewidziane sytuacje. Prawidłowo, jedyne co powinniśmy robić z wyjątkami w naszym kodzie, to łapać wyjątki pochodzące z zewnętrznych bibliotek i funkcji.
Zamiast rzucać wyjątkiem, należy w sytuacji niepowodzenia wywołać odpowiednią metodę interfejsu prezentera i przerwać wykonywanie dalszego kodu.

Dlaczego? Ponieważ, powoduje to szereg problemów:

  • Ekspozycja wyjątków w kontrakcie.
  • Nieprzewidziany przepływ kodu.
  • Niesygnalizowane (poprzez interfejs prezentera) przypadki wyjścia z funkcji.

Comments:4

  1. Co sadzisz na temat “checked exceptions”? – w ich przypadku definicja funkcji jest jawna i metoda otwarcie zglasza ze w niektorych przypadkach bedzie rzucac wyjatkiem.

  2. Pomimo twierdzeń Microsoft uważam, że powinny one być wprowadzone również w C#. Niestety Microsoft już dawno stwierdził, że ich nie będzie bo są “niepotrzebne”. Jeżeli chodzi natomiast o kod biznesowy, to nadal uważam, że lepiej dodać metodę interfejsu prezentera niż rzucić wyjątek. Jest tak dlatego, że moim zdaniem wyjątki nie powinny służyć komunikacji z UI (tylko z bibliotek do kodu biznesowego jako API programistyczne) oraz, że zaburzają (zrywają) przepływ wykonania kodu.
    Kolejnym powodem takiego podejścia jest łatwość pisania testów jednostkowych (przez stworzenie mock’a implementacji jednego interfejsu) zamiast implementacji mock’a oraz łapania wyjątków.

  3. Z tym się nie zgodzę kompletnie. Wyjątki w kodzie biznesowym pozwalają na BARDZO wiele i niosą ogromne korzyści. Kwestia ich odpowiedniego wykorzystania. Tutaj się kiedyś o tym rozpisałem: http://www.maciejaniserowicz.com/2014/06/09/custom-exceptions/ .
    Każdy, nawet najprostszy scenariusz, niesie za sobą przypadki “WYJĄTKOWE”. Stąd: wyjątki. Wyjątkowe, a nie “nieprzewidziane”.
    Twierdzenie że “trzeba wywołać coś na presenterze” zakłada że każdy system ma presentery – a tak przecież nie jest.

    1. Tak, zgadza się. Zakładam, że zawsze istnieje prezenter. Oczywiście piszę tu o sytuacji idealnej i do tego się odnoszę. We wcześniejszych postach prezentowałem wizję “czystej” architektury do której tu się odnoszę.

      Tak jak napisałem, problemem wyjątków brak czytelnej informacji dla “użytkownika” logiki, co może się zdarzyć. Zdecydowanie wolę podejście, gdy klasa definiująca logikę (interactor), definiuje też interfejs komunikacji wyjściowej (IInteractorPresenter).

      Ma tą taką dodatkową zaletę, że jak zaczyna nam się mnożyć ilość metod w prezenterze, to od razu widać że odpowiedzialność logiki jest zbyt rozbudowana.

Leave a Reply

Your email address will not be published. Required fields are marked *