bo czytam o exceptions tu i tam i często mowa jest o tym że:
- - "Wielopoziomowe" try catch usprawnia pracę, np. łapiesz wyjątek, w catchu wykonujesz jakąś akcję (ustawiesz pole Status w encji na "ERROR") i sypiesz wyjątkiem wyżej, funkcja wyżej wykonuje kolejną akcję jak np logowanie błędu etc.
- - wyjątki wyrzucać do możliwie najbliższego poziomu wyżej, nie rozgłaszam całemu światu że jest problem - jeśli mogę naprawić problem robię to możliwie najszybciej.
- -Extending Exceptions for Abstraction
- każda warstwa powinna mieć swój własny typ wyjątku
- czyli wyjątek w warstwie Model winien być schwytany w kontrolerze
-.. i naparwiony lub owinięty i puszczony dalej jako wyj. kontrolera
- albo jeśli biblioteka Twitter wyrzuci wyjątek
-.. to klasa jej używająca owija go i wyrzuca nowy.
- dzięki temu wiem gdzie wyjątek powstał i zachowana jest abstrakcja!
- Wykorzystuje się tu metodę Exception::getPrevious() - - owijanie exceptions ::getPrevious() i re-thrown
- używam jakiegoś 3rd part library, który wyrzuca jakieś wyjątki
- te wyjątki bąbelkują i stają się częścią mojego API
- używam annotations @throws w własnych metodach z klasami wyjątków
- i problem jest gdy wyjątki 3rdPL zmieniają nazwy lub dodają nowe
- i muszę zmieniać annotations @throws w własnych metodach
- [!]ZATEM jeśli moje API nie może poradzić sobie z wyjątkiem 3rdPL:
- to powinno owinąć i wyrzucić nowy jako wyjątek nowego poziomu
- Dzięki temu nie jestem uzależniony od zmian w 3rdPL (wz. adapter)
a w Symfony jeb, i od razu jestem na strychu przez kernel::handle w listenerze. Nie powiem, ta opcja bardziej mi pasuje, jest wygodniejsza. Na mój rozum nie ma róznicy kiedy wyjątek jest łapany, Czy złapię go na 2 piętrze czy na strychu, przecież i tak żaden kod nie jest robiony póki nie zostanie złapany wyjątek. A w listenerze wyjątku mogę znowu puścić kod od parteru. (zastrzegam, że mam prawie zerowe doświadczenie w używaniu wyjątków.)