@bogdans, absolutnie się z Tobą nie zgadzam, nie ucz ludzi złych wzorców. Korzystanie z wyjątków nie jest aż tak kosztowne, żeby było priorytetem. A że optymalizuje się tylko wąskie gardła, to nie widzę żadnego uzasadnienia do niekorzystania z wyjątków poza kilkoma krytycznymi miejscami w aplikacji.
Dlaczego korzystać z wyjątków, a nie statusów? Wyobraź sobie, że w każdym miejscu, gdzie korzystasz z metody która zwraca status zamiast rzucać wyjątkiem, musisz sprawdzać i obsługiwać ten status. Masz np. pięć takich wywołań w jednej metodzie i każde przykrywasz takim lub podobnym pseudokodem status = metoda(); if (status != OK) return status;
. Jak to wpływa na czytelność kodu? Co się stanie, jeśli w którymś miejscu zapomnisz sprawdzić zwrócony status? Co jeśli metoda oprócz statusu ma zwrócić wynik obliczeń albo jakiś model? Jak dowiesz się kilka poziomów stosu wywołań niżej (np. w loggerze), która konkretnie metoda się nie powiodła?
Tymczasem obsługa wyjątku może być jedna, niezależnie od tego, która metoda z całego drzewka wywołań się wywaliła. Ponadto wyjątek gwarantuje, że kod nie wykona się dalej w normalny sposób, nawet jeśli zapomnisz o tym, że metoda taki wyjątek rzuca. Całą pulę wyjątków możesz obsłużyć w jednym miejscu, tj. wywołujesz wcześniej wspomniane pięć metod, nie musisz wyniku każdej z nich obsługiwać w osobnym try/catch z returnem tylko robisz jeden catch, w nim logujesz treść wyjątku i rzucasz wyjątkiem dalej. Jedno miejsce, bez dodatkowych if'ów, bez dodatkowych modeli i bez parametrów przekazywanych przez referencję. W skrajnym przypadku do obsługi wyjątków wystarczy jeden globalny handler i podczepiony do niego logger. Kod jest krótszy i bardziej czytelny, trudniej popełnić błąd.
Minister zdrowia ostrzega: używanie statusów zamiast wyjątków może spowodować raka.