Wszyscy pieją nad #spring i w sumie ja też jestem zachwycony, ale czasami natrafiam na takie ściany w tym szkielecie, że to głowa mała. Do mojego topa, o którym zaraz wspomnę doszło wczorajsze:
Jeśli masz projekt ze Spring + Hibernate + JPA i wygenerujesz plik JAR ze wszystkim zależnościami to JAR nie będzie działać, jeśli w projekcie nie ma chociaż jednej klasy z adnotacją @Entity. Oczywiście ten sam kod, odpalany z poziomu IDE działa bez problemu.
Przyznam, że nadal moim TOP1 był blok w kodzie Spring Framework:
try{ //kod } finally{ //kod } w którym wywalało wyjątek, lecący w kosmos :)
@KotoFan: @NiebieskaSowa: A co w tym dziwnego? Wyjątek sobie poleci i zostanie obsłużony. Być może w tym miejscu nie wiadomo, jak go obsłużyć, a trzeba dokonać pewnego sprzątania bez względu na to, czy wykonanie było poprawne, czy nie. Często się tego używa w zastosowaniach współbieżnych chociażby.
@leoha: @nachteil: Panowie a mam do was pytanie odnośnie łapania wyjątków (#java) czy jest jakiś sens łapać wyjątki w try {...} catch (Throwable ex) {...} ? Czy to nie ma większego sensu ?
@nachteil: @leoha: powiem tak... wyjątek nie był nigdzie obsłużony. @NiebieskaSowa: gdzieś w spring security przy robieniu funkcji remamber me, część z zapisem do bazy danych
@KotoFan: A jesteś pewien, że tam leciał wyjątek? Jeśli to był zgłoszony wyjątek, to musiał zostać obsłużony, bo by się nie skompilowało. Jeżeli niezgłoszony, to wątpię, aby twórcy springa go łapali, bo to zła praktyka. Więc stawiam, że to finally było po to, żeby na pewno jakaś akcja została wykonana po zakończeniu metody - cleanup, logowanie, zmiana stanu jakichś zmiennych, etc. Czyli dokładnie to, do czego się wykorzystuje ten idiom.
@nachteil: no masz rację w sumie. Lecieć leciał. Problem był z tym, że pole w bazie danych było złego typu i nie umiał zmapować na obiekt. Efekt był taki, że cała funkcjonalność nie działała, a nie było o tym żadnej informacji.
@KotoFan: @nachteil: @NiebieskaSowa: Tak jeszcze dodam może kogoś zainteresuje, że idiom try-finally był tak powszechny że od Java7 dostępna jest specjalna konstrukcja try-with-resources.
Jeśli masz projekt ze Spring + Hibernate + JPA i wygenerujesz plik JAR ze wszystkim zależnościami to JAR nie będzie działać, jeśli w projekcie nie ma chociaż jednej klasy z adnotacją
@Entity. Oczywiście ten sam kod, odpalany z poziomu IDE działa bez problemu.Przyznam, że nadal moim TOP1 był blok w kodzie Spring Framework:
try{//kod
}
finally{
//kod
}
w którym wywalało wyjątek, lecący w kosmos :)
Macie podobne doświadczenia?
#java trochę #programowanie też
@NiebieskaSowa: try-finally bez catcha nie jest niczym dziwnym przecież.
r = new LeakyThing();try { useResource(r); }
finally { r.release(); }
czy jest jakiś sens łapać wyjątki w
try {...}
catch (Throwable ex) {...}
?
Czy to nie ma większego sensu ?
http://stackoverflow.com/questions/6083248/is-it-a-bad-practice-to-catch-the-throwable
@NiebieskaSowa: gdzieś w spring security przy robieniu funkcji remamber me, część z zapisem do bazy danych
Tak jeszcze dodam może kogoś zainteresuje, że idiom try-finally był tak powszechny że od Java7 dostępna jest specjalna konstrukcja try-with-resources.
https://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html