C++ to nie moja bajka, jednak piszę w języku o zbliżonym poziomie abstrakcji, więc co nieco ogólnie.
Pytanie jest następujące: Jak dużą uwagę poświęcacie w pracy na obsługę wyjątków?
Dużą, dlatego że wyjątki są i będą rzucane, więc trzeba je łapać i obsługiwać.
Nie można też dopuścić do sytuacji, w której wyjątku się nie złapie w odpowiednim miejscu i nie obsłuży, bo to może zaowocować np. wyciekami pamięci lub zdestabilizowaniem obiektu. Nie można też pozwolić na to, aby wyjątek w ogóle nie został złapany. Bo wstyd, gdy użytkownik dostanie w twarz komunikatem w stylu Access Violation at address …
.
U mnie w firmie jest tego mnóstwo, praktycznie dla każdej metody pisany jest try-catch
nawet jeżeli to zwykły setter.
Widziałem, używałem i używam setterów rzucających wyjątki, ale nie pamiętam, abym musiał je łapać i obsługiwać w setterze. Jeśli dane wejściowe są niepoprawne (luźny przykład: indeks spoza zakresu), to odpowiednio reaguje się (lub nie, zależy od sytuacji), a następnie tworzy i rzuca wyjątek – niech sobie frunie, bo gdzieś ”wyżej” jest łapany i obsługiwany oraz ew. puszczany dalej, jeśli sytuacja tego wymaga.
Inna sprawa to sytuacja, w której ktoś zamiast skorzystać z prostej instrukcji warunkowej do obsługi sytuacji wyjątkowej (nie wyjątku), tworzy blok try
, w nim warunkiem waliduje dane wejściowe i rzuca wyjątek tylko po to, aby go w tym samym bloku złapać i obsłużyć. Bez komentarza…
Jak jest u was?
Elastycznie jest, bo świat nie jest czarno-biały.
Najważniejsze jest to, aby utrzymywać jak najwyższą czytelność kodu i aby reagować na każdy możliwy błąd w odpowiedni sposób. Propagacja wyjątków musi być prawidłowa, tak samo jak przepływ sterowania, do czego się zawsze dąży. Dla mnie dobry kod to taki, który zabezpiecza wszystkie przypadki, stąd zabawa w „co jeśli…?” jest na porządku dziennym.
Czasem zdarza mi się ”przyjanuszować”, np. używając Pokemon Exception Handling, jednak jeśli w danym bloku catch
(u mnie except
) należy wykonać dokładnie te same czynności bez względu na klasę wyjątku, to co mi szkodzi. Taki sposób jest krótki i jednoznaczny, więc każdy zrozumie.
Tyle że ze mną jest trochę inaczej, bo nie boję się używać konstrukcji powszechnie napiętnowanych, skoro w danej sytuacji taka konstrukcja pozwala zwiększyć czytelność kodu i ułatwić jego utrzymanie. To trochę jak z goto
– nie używam, jednak samo jego istnienie mi nie przeszkadza, jeśli dzięki niemu łatwiej zrozumieć o co chodzi. ;)