On 26.05.2012 12:38, Piotr Przybylak wrote:
> Ja nie napisałem, że nie używam wyjątków, tylko że nie nie używam
> wyjątków sprawdzanych.
> Pisane przeze mnie metody nie zwracają wyjątków sprawdzanych a jak
> wywołuję czyjąś (czy z zewnęrznej biblioteki albo JDK) która zgłasza
> wyjątki sprawdzane to opakowuję ją w try catcha który opakowuje ją w
> wyjątek niesprawdzany.
>
> 1. W ten sposób klient mojej metody sam może zdecydować czy chce
> obsłużyć wyjątek czy nie.
> 2. Wolę ryzyko, że ktoś zapomni obsłużyć wyjątek i dostanie błąd na
> produkcji niż,
> że ktoś zmuszony do jego obsługi przez kompilator nie będzie wiedział
> co z nim zrobić i go "połknie".
To ja jeszcze dodam, że wyjątki typu checked naruszają open/close principle.
Powiedzmy że masz serwis który korzysta z interfejsu repozytorium. I
możesz mieć różne implementacje repozytorium. Na razie masz opartą na
bazie danych. Chcesz dodać opartą na plikach. I co, dodajesz teraz
IOException do interfejsu?
W C# checked exceptions z tego powodu w ogóle nie ma.
Oczywiście, powstaje pytanie, skąd wiesz jakie wyjątki masz obsłużyć?
Odpowiedź bywa zaskakująca: jeśli to istotne, dokumentacja to powie.
Zacytuję jeszcze wójka Boba z clean code'a (rozdział "Use Unchecked
Exceptions"):
"The debate is over. For years Java programmers have debated over the
benefits and liabilities of checked exceptions. [..]
Consider the calling hierarchy of a large system. Functions at the top
call functions below them, which call more functions below them, ad
infinitum. Now let’s say one of the lowest level functions is modified
in such a way that it must throw an exception. If that exception is
checked, then the function signature must add a throws clause. But this
means that every function that calls our modified function must also be
modified either to catch the new exception or to append the appropriate
throws clause to its signature. Ad infinitum. The net result is a
cascade of changes that work their way from the lowest levels
of the software to the highest! Encapsulation is broken because all
functions in the path of a throw must know about details of that
low-level exception. Given that the purpose of exceptions is to allow
you to handle errors at a distance, it is a shame that checked excep-
tions break encapsulation in this way. Checked exceptions can sometimes
be useful if you are writing a critical library: You must catch them.
But in general application development the dependency costs outweigh
the benefits."
> Pisząc o specjalnym typie masz na myśli coś w stylu "Maybe" ? Na razie
> tylko o tym czytałem, nie używałem na razie w praktyce.
Czytelniejsze niż zwracanie nulla, pod warunkiem że wbudowane ładnie w
język (np. C#).
--
Jakub Nabrdalik
blog.solidcraft.eu