Dlaczego "throws Exception" przy każdym teście jest złe?

193 views
Skip to first unread message

Marcin Zajączkowski

unread,
May 25, 2012, 7:43:47 PM5/25/12
to warszawa-dp
Witajcie

Trafi�em ostatnio na fajn� bibliotek� awaitility [1], potrafi�c�
odczeka� kwant czasu w oczekiwaniu na spe�nienie warunku asercji (co�
jak verification with timeout w Mockito - szczeg�lnie przydatne przy
dzia�aniach asynchronicznych).

Co mi si� w niej nie podoba, to fakt, �e g��wna jej metoda rzuca
Exception, co skutkuje konieczno�ci� dodania go do sygnatury ka�dego
testu. Osobi�cie nie stosuj� tej konwencji i "void testXXX() throws
Exception" uwa�am za pozosta�o�� z JUnit 3. Jak dla mnie zaciemnia kod
ukrywaj�c miejsca, kiedy testowane metody (albo te u�ywane w te�cie)
rzucaj� jaki� sprawdzalny wyj�tek. Chcia�bym odezwa� si� w bugu
dotycz�cym tego tematu, ale ch�tnie bym doda� tam jakie� inne argumenty.

Dlaczego jeszcze uwa�acie, �e "throws Exception" przy ka�dym te�cie jest
z�e?

[1] - https://code.google.com/p/awaitility

Pozdrawiam
Marcin

--
http://blog.solidsoft.info/ - Working code is not enough

Piotr Przybylak

unread,
May 26, 2012, 6:01:45 AM5/26/12
to warsz...@googlegroups.com
W dniu 26 maja 2012 01:43 użytkownik Marcin Zajączkowski <msz...@wp.pl> napisał:

> testu. Osobiście nie stosuję tej konwencji i "void testXXX() throws
> Exception" uważam za pozostałość z JUnit 3.

Wydaje mi się że to nie ma nic wspólnego z samą wersją JUnita.
W wersji 3 też nie musisz pisać throws Exception.

> Jak dla mnie zaciemnia kod
> ukrywając miejsca, kiedy testowane metody (albo te używane w teście)
> rzucają jakiś sprawdzalny wyjątek. Chciałbym odezwać się w bugu
> dotyczącym tego tematu, ale chętnie bym dodał tam jakieś inne argumenty.
>
> Dlaczego jeszcze uważacie, że "throws Exception" przy każdym teście jest
> złe?

Zaciemnianie kodu, to wydaje mi się jedyny (ale ważny) argument
przeciwko "throws Exception" w metodach testowych. Nie są wołane w
kodzie produkcyjnym, więc przynajmniej to zaśmiecenie nie wycieka do
reszty kodu.
Dla ludzi, którzy tak jak ja zarzucili całkiem używanie wyjątków
sprawdzanych w aplikacji jest to tym bardziej upierdliwe.


--
Pozdrawiam
Piotr Przybylak

Marek Kirejczyk

unread,
May 26, 2012, 6:23:05 AM5/26/12
to warsz...@googlegroups.com
Zawsze wydaje się trochę skrajnym podejściem, możesz trochę więcej powiedzieć? :)

Np. jak masz repozytorium, które deserialzuje agregat z połączenia sieciowego, to co dokładnie robisz jak leci IOException?
Zwracanie specjalnego typu wydaje się własną implementacją wyjątków i trochę bezsensu. A jakoś chce przekazać np do warstwy interfejsu zeby pojawił się msgbox "retry? [ok] [cancel]".

Marek


2012/5/26 Piotr Przybylak <piotr.p...@gmail.com>



--
Marek Kirejczyk
marek.k...@gmail.com

Piotr Przybylak

unread,
May 26, 2012, 6:38:53 AM5/26/12
to warsz...@googlegroups.com
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".

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.

Pozdro
Piotrek

W dniu 26 maja 2012 12:23 użytkownik Marek Kirejczyk
<marek.k...@gmail.com> napisał:
--
Pozdrawiam
Piotr Przybylak

Jakub Nabrdalik

unread,
May 26, 2012, 7:09:31 AM5/26/12
to warsz...@googlegroups.com
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

Marek Kirejczyk

unread,
May 26, 2012, 7:27:40 AM5/26/12
to warsz...@googlegroups.com
He he, okej teraz to ma sens :)

Już od dłuższego czasu wydawało mi się, że checked exceptions to zło.
Dzięki za uzupełnienie wiedzy i dodanie kontekstu :)


Marek

2012/5/26 Jakub Nabrdalik <jak...@gmail.com>



--
Marek Kirejczyk
marek.k...@gmail.com
Reply all
Reply to author
Forward
0 new messages