Die ewige Diskussion um Checked und Unchecked Exceptions
Philip May
obwohl anfangs Sun die Checked Exceptions von Java als großen Vorteil verkauft hat, gibt es ja unter Anderem auch im Spring Umfeld Leute die sagen, dass Checked Eceptions oft nicht sinnvoll sind. Sie werden ja eh nur weiter geworfen und ich kann nur in den seltensten Fällen etwas mit ihnen anfangen.
Nun gibt es ja aber in mehrschichtigen Systemen die Anforderung, dass jede Domäne oder auch Schicht seine eigenen Exceptions wirft. Kommt also eine "message queue nicht vorhanden" exception in der Business Logik an, dann soll ich der darübergelegenen Schicht etwas anderes sagen. Ihr also nicht diese low level exception an den Kopf werden. Das wird ja meist mit Exception Chaining gemacht. Um aber Exceptions Chainen zu können, muss ich die eine ja fangen um sie in den Constructor der nächsten hineinstecken zu können.
Nun entsteht für mich der Widerspruch. Einerseits heißt es "nimm unchecked exceptions denn Du wirst sie ja eh nur weiter werfen" andererseits heißt es "gib die low level exceptions nicht einfach weiter, sondern transformiere sie". Ist das nicht ein Widerspruch?
Kann mir eventuell jemand helfen diesen Widerspruch aufzuklären und etwas mehr Klarheit in diese Fragestellung zu bringen?
Danke,
Philip
Eberhard Wolff
Philip May wrote:
> Hallo SUGG,
>
> obwohl anfangs Sun die Checked Exceptions von Java als großen Vorteil
> verkauft hat, gibt es ja unter Anderem auch im Spring Umfeld Leute die
> sagen, dass Checked Eceptions oft nicht sinnvoll sind. Sie werden ja eh
> nur weiter geworfen und ich kann nur in den seltensten Fällen etwas mit
> ihnen anfangen.
Checked Exceptions sind eine Besonderheit von Java. Es gibt sonst keine
Programmiersprache, die einen solchen Mechanismus kennt. Es gibt zwar
ähnliche Konzepte in CLU oder Modula-3 (nicht Modula-2), aber das war es
dann auch. Wenn Checked Exception so toll sind - warum sind sie dann zum
Beispiel nicht in C# enthalten? Ich denke, Java-Entwickler sollten sich
hier bewusst sein, dass sie die Sprache nutzen, die als einzige ein
solches Konzept hat...
> Nun gibt es ja aber in mehrschichtigen Systemen die Anforderung, dass
> jede Domäne oder auch Schicht seine eigenen Exceptions wirft. Kommt also
> eine "message queue nicht vorhanden" exception in der Business Logik an,
> dann soll ich der darübergelegenen Schicht etwas anderes sagen. Ihr also
> nicht diese low level exception an den Kopf werden. Das wird ja meist
> mit Exception Chaining gemacht. Um aber Exceptions Chainen zu können,
> muss ich die eine ja fangen um sie in den Constructor der nächsten
> hineinstecken zu können.
>
> Nun entsteht für mich der Widerspruch. Einerseits heißt es "nimm
> unchecked exceptions denn Du wirst sie ja eh nur weiter werfen"
> andererseits heißt es "gib die low level exceptions nicht einfach
> weiter, sondern transformiere sie". Ist das nicht ein Widerspruch?
Ich bin der Meinung, dass die Regel "Gib Low Level Exceoption nicht
einfach weiter" Unsinn ist. Wenn man das so implementiert, hat man
folgenden Code z.B. im Service:
public class SomeService {
public void performService()
throws ServiceException {
try {
orderDao.createOrder(new Order());
} catch (SQLException e) {
throw new ServiceException(e);
}
}
}
und dann drüber:
public class SomeController {
public void handleWebRequest() {
try {
someService.performService();
} catch (Exception e) {
e.printStackTrace();
}
}
}
Hier sieht man zum einen, dass der Entwickler des Service überfordert
ist, die Exception sinnvoll zu behandeln. Die landet nur in einem
Log-File oder stdout. Die Anwendung läuft einfach weiter. Und es
interessiert ihn auch nicht, dass es eine ServiceException ist, sondern
er will jeden Fehler so behandeln.
Mit unchecked Exception würde der Fehler von einem Exception-Handler
hoffentlich sinnvoll behandelt werden. In Bezug auf das Chaining sieht
man hier, dass der Entwickler des Service auch mit einer
Low-Level-Exception hätte leben können, da er eh alle Fehler gleich
behandelt. Also hat man im Service die Exception sinnloserweise
gewrappt. Der Code zum Wrappen ist schlicht überflüssig.
Ich glaube, dass Chaining ist mal als "Best Practise" etabliert worden,
weil man dann bei der Benutzung eines Service sicher sein kann, dass man
nur bestimmte Exceptions bekommt (eben Service Exceptions). Aber in der
Realität interessiert den Benutzer das meistens nicht, sondern er fängt
einfach alle Exceptions, so dass das Chaining sinnlos wird.
Ein Sonderfall könnte noch ein entfernter Client sein, dem man nicht
alle Exceptions als .class-Files geben will. Da kann man aber mit einem
Aspekt die Exceptions einfach generisch einwrappen.
Gruß,
Eberhard
--
Eberhard Wolff
Regional Director
SpringSource GmbH
Sitz der Gesellschaft: Uhlandstrasse 75 - D-10717 Berlin
Geschäftsführer: Steven Schuurman, Rod Johnson
Amtsgericht Charlottenburg - HRB 103773 B
Author, "Spring 2 - Framework für die Java Entwicklung"
http://www.spring-buch.de/
Founding Member Java Champions
https://java-champions.dev.java.net/
Mail: eberhar...@springsource.com
Skype: ebr.wolff
Blog: http://JandIandMe.blogspot.com/