Polimorficzne wyjątki - pomysł i wykonanie

W tym wątku najbardziej dziwi mnie to, że to ja mam alkohol w awatarze.

1. Lecą wyjątki (z tego co zrozumiałem, z domeny).
2. Będą dochodzić nowe.
3. Chcecie rozróżniać wyjątki.
4. Wprowadzacie rozwiązania w piątki (wprowadziłem takie rozwiązanie w piątek).

Same problemy :)

Czy macie warstwę, która weryfikuje reguły biznesowe? Czy takiej warstwy brak i weryfikacja jest w domenie i z domeny lecą wyjątki?

Jak się tak zastanowić, to biznesowo wyjątki nie lecą. Taki przykład, w urzędzie wypełniasz formularz (input) i chcesz go przekazać pani w okienku (submit), to nie przyjmie Ci go bez uprzedniego sprawdzenia (validation) czy nie naruszyłeś reguł biznesowych (business rules). Dostałeś kiedyś wyjątek po złożeniu wniosku o coś tam? Raczej nie, dostałeś co najwyżej potwierdzenie przyjęcia wniosku, powiadomienie o zdarzeniu ("Wydano decyzję") + dane skojarzone z eventem ("decyzja"), powiadomienie o zakończeniu postępowania etc.

Bo ta sama logika biznesowa jest wołana z trzech miejsc, jako user, z panelu administratora zupełnie inną drogą jako admin, oraz z crona jako user cron.

Czyli masz ten sam przypadek użycia i 3 aktorów, a to znaczy, że masz problem z SRP, bo 3 różnych aktorów, to potencjalnie 3 powody do zmiany. Może powinieneś mieć 3 różne przypadki użycia, ale załączające wspólny? Wówczas zrobienie weryfikacji przed załączeniem przypadku użycia nie dawałoby powodu do generowania wyjątku.

Dobrze rozumiem, że bierzesz wizytatora i problemy architektoniczne rozwiązujesz na poziomie implementacji?

TomRiddle napisał(a):

MasterBLB napisał(a):

Bracie TomRiddle, a może tak nieco inaczej podejść do zagadnienia [pomysł tak z grubsza]:

1. Stwórz klasę BaseException który będzie zawierał wartość jakiegoś enuma ExceptionType; na chwilę obecną będziesz miał 4 wartości. Będzie trzeba więcej - dokodujesz.
2. Stwórz klasę ExceptionSmth (wymyśl jakąś dobrą nazwę) który będzie siedział w każdym catche'u, i łapał wszystkie wyjątki jakie polecą. Będzie także zawierał mapę <ExceptionType, nazwa dedykowanego dla typu handlera>. Może też zawierać jakieś stany czy coś, w zależności od których obsługa złapanego wyjątku może nieco się różnić.
3. Jeśli złapany wyjątek nie będzie pochodną od BaseException to ma zostać rzucony w świat ponownie.
4. Jak się trafi wyjątek właściwego typu z mapy odczytasz jakiego handlera do niego użyć.
5. Przyda się teraz jakaś klasa HandlerFactory, która stworzy i zwróci obiekt do obsługi wyjątku. To przyda się na sytuacje kiedy czasem coś tam tym obiekcie handlera potrzebowałbyś porzeźbić, np. jakoweś dependency injection mu zapodać zanim wpuścisz do niego wyjątek.
6. Wpuszczasz wyjątek do Handlera, a on robi robotę.

No a to nie byłby specjalny przypadek wizytora, w którym implementacją acceptów jest get() z mapy?

Nie znam tak do końca wzorca wizytor bo jakoś nie miałem okazji w praktyce skorzystać, ale z tego, co znalazłem w sieci wynika, iż ten mój wstępny pomysł to nieco od niego obiega.
Po pierwsze, 1 linię obsługi w jakiś okolicznościach można zrobić w ExceptionSmth, jeszcze przed wyciągnięciem handlera z mapy.
Po drugie, jak się wyciągnie z mapy co zapodać do HandlerFactory aby uzyskać obiekt Handlera to tutaj znów masz wybór - albo dajesz taki defaultowy Handler, albo coś ekstra w nim ustawiasz przed wpuszczeniem do niego wyjątku.
Jeśli dobrze zrozumiałem wzorzec wizytora nie oferuje on możliwości zmiany obiektu obsługującego wyjątek przed wykonaniem operacji, czyli jak wybrałeś do obsługi wizytora SomeVisitor to finito, tylko tego domyślnego użyjesz.

Dlaczego bazowy wyjątek dziedziczy po RuntimeException? Jak wam poleci wyjątek domenowy to zabijacie aplikacje?

Krolik napisał(a):

Dlaczego bazowy wyjątek dziedziczy po RuntimeException? Jak wam poleci wyjątek domenowy to zabijacie aplikacje?

Obsługuję.

Aplikacja nawet nie jest w Javie, więc nie ma checked wyjątków.