Gibt es Performanceeinbußen durch exception handling?

[tfa]

Nein, auch bei solchen Stellen sind unchecked Exceptions vorzuziehen.
Gründe dafür gibt es genug.

http://radio.weblogs.com/0122027/stories/2003/04/01/JavasCheckedExceptionsWereAMistake.html
http://www.mindview.net/Etc/Discussions/CheckedExceptions
http://www.mail-archive.com/hibernate-devel@lists.sourceforge.net/msg04343.html

Vor kurzem gab es hierzu auch eine längere Diskussion. Benutz die Suche.

[tfa]

jule37 schrieb:

zur anderen diskusion: ist es nicht so, dass exceptions auschließlich zur laufzeit auftreten (deshalb ja überhaupt der notwand des exception handlings)? damit wäre doch die bezeichnung RuntimeException völliger unsinn(?)

Natürlich werden alle Exceptions zur Laufzeit geworfen. RuntimeExceptions heißen deswegen so, weil sie automatisch von der Laufzeitumgebung erzeugt werden, um sich z.B. vor Nullpointer-Dereferenzierung oder falschem Class-Casting zu schützen.
Die anderen Exceptions werden eher programmatisch (also durch throw new Exception()) erzeugt und geworfen.

[Gregor]

tfa schrieb:

Nein, auch bei solchen Stellen sind unchecked Exceptions vorzuziehen.
Gründe dafür gibt es genug.

http://radio.weblogs.com/0122027/stories/2003/04/01/JavasCheckedExceptionsWereAMistake.html
http://www.mindview.net/Etc/Discussions/CheckedExceptions
http://www.mail-archive.com/hibernate-devel@lists.sourceforge.net/msg04343.html

Vor kurzem gab es hierzu auch eine längere Diskussion. Benutz die Suche.

Es ist ja nicht so, dass meine Meinung völlig aus der Luft gegriffen ist. Ich kann Dir auch einige Quellen nennen, in denen für meine Ansicht argumentiert wird. Lies zum Beispiel mal "Effektiv Java programmieren". Da steht ne ganze Menge zu diesem Thema drin.

[mal sehen]

ich bin ja mal gespannt wie es in ein paar Jahren mit Exceptions aussieht, oder obs dann schon was besseres gibt.

[tfa]

Gregor schrieb:

Es ist ja nicht so, dass meine Meinung völlig aus der Luft gegriffen ist. Ich kann Dir auch einige Quellen nennen, in denen für meine Ansicht argumentiert wird. Lies zum Beispiel mal "Effektiv Java programmieren". Da steht ne ganze Menge zu diesem Thema drin.

Dann nenn mal einige aktuelle Quellen.
Das Buch von Josh Bloch hab ich zufällig im Regal stehen. Er beschreibt ziemlich genau das ursprüngliche von Sun entworfene Exception-Konzept, was verständlich ist, wurde das Buch doch in Kooperation mit Sun Microsystems herausgegeben, wo Bloch auch angestellt war.
Außerdem ist der Text aus dem Jahr 2001. Damals war die Auffassung noch nicht so verbreitet, dass checked Exceptions schlecht seien (HibernateException war z.B. noch checked).
Vor 7 Jahren habe ich da auch noch dran geglaubt, aber mittlerweile hat sich meine Meinung geändert.

Aber völlig falsch sind Blochs Tips trotzdem nicht:

Effektiv Java programmieren schrieb:

Vermeiden Sie den unnötigen Einsatz von geprüften Ausnahmen

Es scheint also doch ein Problem mit checked Exceptions zu geben?

Effektiv Java programmieren schrieb:

Geprüfte Ausnahmen für behebbare Situationen

Auch richtig. Ich behaupte, der Designer eines Frameworks oder API kann gar nicht entscheiden, ob eine Ausnahmesituation für den Verwender seines Codes behebbar ist oder nicht. In den allermeisten Fällen wird sie nicht behebbar sein - nach meiner Erfahrung.

Effektiv Java programmieren schrieb:

[Geprüfte Ausnahmen sind] gerechtfertigt, wenn die Ausnahmebedingung nicht durch korrekte Benutzung des APIs zu verhindern ist und außerdem die Programmierer, die das API benutzen, etwas Sinvolles tun können, wenn sie mit der Ausnahme konfrontiert werden. Wenn nicht beides zutrifft, dann ist eine geprüfte Ausnahme besser. Sie sollten sich fragen, wie der Programmierer die Ausnahme behandeln wird.

Und das ist häufig, die Exception zu ignorieren, zu loggen, weiterzuwerfen oder printStacktrace() aufzurufen. Mit Sicherheit nichts Sinnvolles.

Wenn du in einer (closed source) Individualsoftware durch selbstdefinierte checked Exceptions dich selbst zur Fehlerbehandlung zwingen willst, so ist das in Ordnung. Aber in wiederverwendbaren Bibliotheken (also auch der Standard-API) haben die nichts zu suchen.
Leider werden wir sie wohl nie wieder los.

[DEvent]

Gregor schrieb:

DEvent schrieb:

Nenn doch bitte diese Stellen.

Jede Stelle, an der bei völlig korrekten Programmen unverhersehbare Ereignisse auftreten können, die eine Reaktion des Programms erfordern. Der IO-Bereich und die Netzwerkkommunikation sind diesbezüglich Paradebeispiele. Aber es kann ja auch sein, dass solche Fälle in Anwendungsgebieten auftreten, die nichts mit der Standardbibliothek zu tun haben.

Dies sind eigentlich alle Exceptions, eben die RuntimeExceptions ausgenommen, da diese auf einen Bug im Programm hinweisen, der bei korrekten Programmen nicht auftreten darf.

Wieso macht dann aber z.B. Hibernate einen eigenen Zweig von unchecked-Exceptions auf? Kenn mich zwar bei Hibernate nicht besonders aus, aber eine TransactionException

Indicates that a transaction could not be begun, committed or rolled back.

hoert sich nicht an einen Programmier-Bug an, sondern an eine Ausnahme fuer die der Programmierer nichst kann.

In Java muesste der Compiler eigentlich verhindern das man von RuntimeException erben kann. Aber dann wuerde endlich das Misskonzept der Checked-Exceptions offensichtlich.

[Gregor@Uni]

DEvent schrieb:

Wieso macht dann aber z.B. Hibernate einen eigenen Zweig von unchecked-Exceptions auf? Kenn mich zwar bei Hibernate nicht besonders aus, aber eine TransactionException

Indicates that a transaction could not be begun, committed or rolled back.

hoert sich nicht an einen Programmier-Bug an, sondern an eine Ausnahme fuer die der Programmierer nichst kann.

Naja, das ist halt eine Frage des Designs. Da gibt es meistens kein richtig und kein falsch, sondern nur unterschiedliche Sichtweisen, wie man irgendetwas designen sollte. Die Hibernate-Leute sind anscheinend der gleichen Auffassung wie tfa, dass checked Exceptions eigentlich keinerlei Berechtigung in einem Framework haben. Ich sehe das halt etwas anders. Da stecken zwei unterschiedliche Denkweisen dahinter. Die Leute, die gegen checked Exceptions sind, sind wohl in erster Linie Pragmatiker: Sie haben ne ganze Menge programmiert und die try-catch-Blöcke, die sie in diesem Zusammenhang schreiben mussten, praktisch fast noch nie gebraucht. Natürlich kommt man dann zu dem Schluss, dass man einen Exception-Mechanismus nutzen sollte, der dieses nervige Konstrukt nicht unbedingt benötigt. Die Leute, die für checked Exceptions sind, sehen das ganze vermutlich eher aus einer theoretischeren Sicht. Da geht es um Prinzipien, die man beachten sollte, um stabile und fehlertolerante Programme zu schreiben.

Und seien wir mal ehrlich: Wenn man nicht gezwungen wird, um irgendeinen Methodenaufruf herum einen try-Block zu bauen, dann ignoriert man einfach, dass irgendwo in der Doku steht, dass die Methode eine bestimmte RuntimeException schmeißen könnte. Darauf wird man erst dann wieder aufmerksam, wenn das Programm im Betrieb wegen dem Auslösen so einer Exception unplanmäßig terminiert wird und damit alle temporären Daten im Arbeitsspeicher nicht mehr rekonstruierbar sind.

[tfa]

Gregor@Uni schrieb:

Naja, das ist halt eine Frage des Designs. Da gibt es meistens kein richtig und kein falsch, sondern nur unterschiedliche Sichtweisen, wie man irgendetwas designen sollte. Die Hibernate-Leute sind anscheinend der gleichen Auffassung wie tfa, dass checked Exceptions eigentlich keinerlei Berechtigung in einem Framework haben. Ich sehe das halt etwas anders. Da stecken zwei unterschiedliche Denkweisen dahinter. Die Leute, die gegen checked Exceptions sind, sind wohl in erster Linie Pragmatiker: Sie haben ne ganze Menge programmiert und die try-catch-Blöcke, die sie in diesem Zusammenhang schreiben mussten, praktisch fast noch nie gebraucht. Natürlich kommt man dann zu dem Schluss, dass man einen Exception-Mechanismus nutzen sollte, der dieses nervige Konstrukt nicht unbedingt benötigt. Die Leute, die für checked Exceptions sind, sehen das ganze vermutlich eher aus einer theoretischeren Sicht.

Gute Zusammenfassung

Gregor@Uni schrieb:

Und seien wir mal ehrlich: Wenn man nicht gezwungen wird, um irgendeinen Methodenaufruf herum einen try-Block zu bauen, dann ignoriert man einfach, dass irgendwo in der Doku steht, dass die Methode eine bestimmte RuntimeException schmeißen könnte. Darauf wird man erst dann wieder aufmerksam, wenn das Programm im Betrieb wegen dem Auslösen so einer Exception unplanmäßig terminiert wird und damit alle temporären Daten im Arbeitsspeicher nicht mehr rekonstruierbar sind.

Das ist gut! Fehler sollten möglichst früh und möglichst hart zu schlagen (natürlich während der Testphase und nicht im Produktivbetrieb).
Was nützen mir zwangsweise behandelte Exceptions, die dann doch ignoriert werden oder in megabyteweise Logdateien verschwinden? Der Auto-Bugfixing der IDE macht das so schön einfach.
Dann doch lieber eine RuntimeException, die bis nach ganz oben geworfen, in ein Bugreport verpackt und ans Backoffice geschickt wird. So wird der Fehler wenigstens gefixt und nicht toleriert.
Pragmatismus ist wichtig (lernt man leider nicht an der Uni).

[Gregor@Uni]

tfa schrieb:

Das ist gut! Fehler sollten möglichst früh und möglichst hart zu schlagen (natürlich während der Testphase und nicht im Produktivbetrieb).
Was nützen mir zwangsweise behandelte Exceptions, die dann doch ignoriert werden oder in megabyteweise Logdateien verschwinden?

Ich sehe es durchaus auch so, dass checked Exceptions nicht zur Abfederung von Bugs da sind. Die sind für Ausnahmesituationen da, die nicht durch das Programm selbst hervorgerufen werden. Damit treten sie typischerweise erst im realen Einsatz auf und nicht während der Testphase. Du kannst in den catch-Blöcken natürlich alles mögliche machen und Du hast auch Recht, dass man schnell dazu neigt, trotz vorhandenem catch-Block keine vernünftige Ausnahmebehandlung durchzuführen. Aber alleine ein vernünftiges Logging kann schon sehr sinnvoll sein. Wenn der Kunde einem nämlich irgendwann sagt "Funktioniert nicht!", kann man dem Problem wenigstens auf den Grund gehen, weil man mit den Log-Dateien etwas in der Hand hat, was man ernsthaft auswerten kann. Aber Du hast schon Recht: Eigentlich sollte man in den catch-Blöcken eine sinnvollere Ausnahmebehandlung durchführen.

[tfa]

Gregor@Uni schrieb:

Ich sehe es durchaus auch so, dass checked Exceptions nicht zur Abfederung von Bugs da sind. Die sind für Ausnahmesituationen da, die nicht durch das Programm selbst hervorgerufen werden. Damit treten sie typischerweise erst im realen Einsatz auf und nicht während der Testphase.

Das ist falsch. Gerade solche Ausnahmesituationen können (und müssen) gut getestet werden. Richtige Bugs (also unchecked Exceptions) findet man vielleicht nicht immer, aber geplante Exceptions werden getestet. Sonst ist deine Testabdeckung schlecht.

Gregor@Uni schrieb:

Du kannst in den catch-Blöcken natürlich alles mögliche machen und Du hast auch Recht, dass man schnell dazu neigt, trotz vorhandenem catch-Block keine vernünftige Ausnahmebehandlung durchzuführen. Aber alleine ein vernünftiges Logging kann schon sehr sinnvoll sein. Wenn der Kunde einem nämlich irgendwann sagt "Funktioniert nicht!", kann man dem Problem wenigstens auf den Grund gehen, weil man mit den Log-Dateien etwas in der Hand hat, was man ernsthaft auswerten kann. Aber Du hast schon Recht: Eigentlich sollte man in den catch-Blöcken eine sinnvollere Ausnahmebehandlung durchführen.

Ich hab auch überhaupt nichts gegen Logging. Unchecked Exceptions werden natürlöich auch geloggt, nur eben nicht sofort da, wo sie geworfen werden.

[don_basto]

Hallo,

mal eine Frage zum Einsatzgebiet von 'checked exceptions':

Gregor@Uni schrieb:

Die sind für Ausnahmesituationen da, die nicht durch das Programm selbst hervorgerufen werden. Damit treten sie typischerweise erst im realen Einsatz auf und nicht während der Testphase.

Was bedeutet das eigentlich praktisch?

Aus meiner Erfahrung kann man mit 'unchecked execeptions' prima auskommen, da man keinen Extra-Kode schreiben muss, wenn man auf die Exception nicht reagieren kann und sich die Exceptions nicht in den Schnittstellen niederschlagen.

Die 'checked exceptions' haben einen Vorteil: Sie zwingen den Entwickler zu reagieren. Gerade an Komponenten-/Systemgrenzen kann es sehr hilfreich sein, weil man hier häufig entscheiden kann, was zu tun ist, wenn eine Teilsystem ausfällt etc.

BTW: Gerade das Verhalten bei 'checked_exceptions' sollte gut getestet sein, da stimme ich tfa zu.

Grüße
don_basto

[jule37]

ein bug ist doch nicht zwangsläufig eine exception, sondern einfach nur unvorhergesehenes / ungewolltes verhalten des programms.

ich persönlich finde checked exceptions eine gute sache um schlampige programmierer dazu zu zwingen sauberer zu programmieren. vor allem in der file io ist es extrem wahrscheinlich, dass exceptions fliegen, wenn der user was falsches eingibt, also muss die exception eh gehandelt werden. warum also nicht gleich checked? es macht doch keinen sinn, eine exception nicht zu handlen, die auf jeden fall irgendwann mal geworfen wird, also kann man gleich den programmierer zwingen, sie zu behandeln, meiner meinung nach.

[don_basto]

jule37 schrieb:

ich persönlich finde checked exceptions eine gute sache um schlampige programmierer dazu zu zwingen sauberer zu programmieren.

Das Problem ist aber, dass man nicht immer sofort eine geeignete Reaktion parat hat, sondern die Excpetion lieber weiterreichen will. Und beim Weiterreichen machen die 'checked Exceptions' einen ziemlichen Aufwand. Ich verpacke diese dann lieber in 'unchecked Exceptions' um die Fehlerbehandlung nicht in jedem Aufrufer durchführen/dokumentieren zu müssen.

[tfa]

Checked Exceptions fördern schlampige Programmierung.

[byto]

In der Praxis siehst Du ständig sowas:

try { 
  method.invoke(...); 
} catch (FooException e) {
  e.printStacktrace();
}

Wenn die Methode dann vielleicht noch mehr als eine checked Exception wirft, sieht häufig was noch viel schlimmeres:

try { 
  method.invoke(...); 
} catch (Exception e) {
  e.printStacktrace();
}

Da werden dann noch direkt alle möglichen RuntimeExceptions mit verschluckt. Schlampige Programmierer werden durch checked Exceptions also sehr häufig noch schlampiger. Und fiese Bugs lassen sich so häufig nur sehr schwer finden, wenn an gewissen Stellen wichtige Exceptions verschluckt werden. Dann doch lieber eine unchecked Exception durchreichen, die man dann gezielt beheben kann, falls sie (überhaupt) auftritt.

Checked Exceptions sind imo nur dann sinnvoll, wenn man (i) keine API für jedermann schreibt und (ii) schon während des Schreibens der Methode klar ist, wie man auf die Ausnahme (in jedem Fall) zu reagieren hat.