Gibt es Performanceeinbußen durch exception handling?

[farbenkombination]

Gregor schrieb:

Gib mal ein Beispiel. Welches Framework meinst Du und was werden da für Exceptions geworfen.

Hibernate, wobei ich das nicht als gutes Framework bezeichnen würde, da daran schon viel zu oft was geändert wurde und man dann dauernd seinen Code ändern darf...

jule37 was soll dieses INSTANCE Ding sein, bei dem man irgendwie nur einmal den Titel angeben kann? Soll jede Applikation nur ein einziges Fenster mit Titel haben dürfen oder für was ist das gut?

[Gregor]

farbenkombination schrieb:

Gregor schrieb:

Gib mal ein Beispiel. Welches Framework meinst Du und was werden da für Exceptions geworfen.

Hibernate, wobei ich das nicht als gutes Framework bezeichnen würde, da daran schon viel zu oft was geändert wurde und man dann dauernd seinen Code ändern darf...

Und was für Exceptions betrifft das da? In welchem Zusammenhang werden die geworfen?

[farbenkombination]

Z.B.:
http://www.hibernate.org/hib_docs/v3/api/org/hibernate/exception/SQLGrammarException.html

Klick dich einfach mal durch die ganzen Exceptions durch und wenn du den Eindruck hast, dass es irgendwie "ungewöhnlich" ist, bist du nicht allein.

[Gregor]

farbenkombination schrieb:

Z.B.:
http://www.hibernate.org/hib_docs/v3/api/org/hibernate/exception/SQLGrammarException.html

Klick dich einfach mal durch die ganzen Exceptions durch und wenn du den Eindruck hast, dass es irgendwie "ungewöhnlich" ist, bist du nicht allein.

Naja, die würde ich vermutlich auch als RuntimeException realisieren. Ist ja praktisch soetwas ähnliches wie eine IllegalArgumentException. Für das, was Dein Programm an SQL-Code produziert, ist Dein Programm selbst verantwortlich. Wenn Code produziert wird, der nicht funktioniert, dann ist das ein Bug im Programm.

Aber ich werde mir die ganzen Exceptions da mal angucken. Ich bin gespannt, was man da so findet.

[farbenkombination]

Das tolle daran ist ja auch, das es bei Hibernate nomral Exceptions gab die in ner anderen Version plötzlich zu Runtime Exceptions wurden. Ganz zu scheigen von den HQL Syntaxänderungen...

[DEvent]

Gregor schrieb:

farbenkombination schrieb:

Z.B.:
http://www.hibernate.org/hib_docs/v3/api/org/hibernate/exception/SQLGrammarException.html

Klick dich einfach mal durch die ganzen Exceptions durch und wenn du den Eindruck hast, dass es irgendwie "ungewöhnlich" ist, bist du nicht allein.

Naja, die würde ich vermutlich auch als RuntimeException realisieren. Ist ja praktisch soetwas ähnliches wie eine IllegalArgumentException. Für das, was Dein Programm an SQL-Code produziert, ist Dein Programm selbst verantwortlich. Wenn Code produziert wird, der nicht funktioniert, dann ist das ein Bug im Programm.

Aber ich werde mir die ganzen Exceptions da mal angucken. Ich bin gespannt, was man da so findet.

Das Problem ist das eine RuntimeException nicht auf die Lebenszeit deines Programms andeutet, sondern auf die JavaVM-Runtime. Ausserdem fliegt eine RuntimeException nur wenn du einen schwerwiegenden Bug in deinem Programm hast, wie das Zugreifen auf eine ungueltige Referenz (NullPointerException), EmptyStackException, usw.

Das sind alles Exceptions die die JavaVM wirft, um anzuzeigen das du einen Bug in deinem Programm hast. Deswegen heist es auch NullPointerException und nicht NullRefernceException, weil eben die JavaVM auf einen null-Pointer zugreift.

Keine API sollte irgendwas von RuntimeException ableiten, also niemals neue NullPointer-Exception deklarieren.

Der einzige Grund, wieso es Hibernate macht, ist es, weil alle RuntimeExceptions unchecked sind.

[jule37]

farbenkombination schrieb:

...
jule37 was soll dieses INSTANCE Ding sein, bei dem man irgendwie nur einmal den Titel angeben kann? Soll jede Applikation nur ein einziges Fenster mit Titel haben dürfen oder für was ist das gut?

es ist die applikation an sich. es enthält das fenster (JFrame), wovon es nur eins geben darf, es enthält einen eigenen event stack, der events (java.awt.InputEvent und dessen subklassen) an das virtuelle windowing subsystem verteilt u.v.m., wobei die erstgenannten dinge im moment die wichtigsten sind.
ich habe mich halt dazu entschieden es so zu implementieren, da es pro prozess nur eine applikation geben darf (und damit nur ein fenster, da fullscreen exclusive und nur einen event stack für das subsystem etc). es ist an mehreren stellen erforderlich auf die in Application enthaltenen objekte zuzugreifen (windowing subsystem muss seine events vom stack holen), aber (imo) völlig unsinnig, dieses applikationsobjekt an alle anderen objekte im konstruktor als parameter zu übergeben.
schwierig präzise auf den punkt zu formulieren, was ich meine, aber ich glaube jetzt ist das wesentliche gesagt

was mich nun interessiert: ist das konzept gut oder eher mangelhaft designed? wenn jemand mit sowas erfahrung hat wäre es toll nen tip zu kriegen. ist ja nicht immer so einfach die entscheidung für was man globale objekte hat und für was bloß parameter.

gruß & danke

edit:
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(?)

[Vevusio]

erstens, zu dem singleton design von der application klasse, ich hätte es auch so gemacht

objekte die von denen man eben nur eine instanz braucht und die zusätzlich noch während dem ganzen programm regelmäßig benötigt werden und deswegen sowieso dauernd existieren solange das programm läuft sind finde ich perfekte kandidaten für singleton klassen

zu den exceptions

erstmal ganz allgemein, man kann finde ich nicht sagen "exceptions sind besser als rückgabewerte"; auch nicht dass sie schlechter sind

man muss sich einfach überlegen was in welchen situationen am ehesten geeignet ist

wenn ich beispielsweise eine methode habe welche ein element in eine liste einfügt in der jedes element nur 1 mal vorkommen darf kann man durchaus anstatt einer ElementAlreadyContainedException einfach den void rückgabewert auf boolean zu ändern und true/false je nachdem ob es eingefügt werden konnte zurück zu geben
entsprechend bei der suchmethode null als rückgabewert zurückgeben statt einer exception

ich finde beides ist eine gute lösung und es kommt einfach auf gewohnheit und persönliche präferenzen an wie man es löst, möglicherweise will man ein kleines programm zum prototyping oder einfach so zum lernen von etwas neuemm oder irgend ein tool programmieren und macht es mit eher wenigen exceptions oder man arbeitet an etwas großem wo man viel wert auf sicherheit etc legt und entschließt sich eher vorwiegend exceptions zu verwenden in kombination mit einem logging mechanismus in dem konstruktor der exceptions

gerade bei methoden die etwas initialisieren bzw viele verschiedene sachen schief gehen können sind exceptions viel nützlicher weil sie mir mehr sagen als [Alles OK? TRUE/FALSE] sondern ich x verschiedene exceptions bekommen kann wo der typ der exceptions allein schon sagt was passiert ist + messages, stack trace usw.

ok das mal dazu, performance mäßig würde ich mir absolut keine gedanken machen, bottlenecks liegen nicht in so sachen wie exceptions oder ob man jetzt pre oder postincrement ++ macht und diesen ganzen sachen die man von vorwiegend c und c++ programmierern dauernd hört

und zu RuntimeExceptions
in c++ ist jede exception eine runtime exception, in java gibt es ka.. ich weiss nicht wie das heisst ich glabe "checked exceptions" oder so, das bedeutet einfach dass die funktion in ihrer definition explizit sagt throws ThisAndThatException und man muss dann auf diese exception checken mit einem try-catch

wo man checked exceptions und wo man runtime exceptions verwenden sollte ist dann wieder so eine sache wo man sich halt überlegen muss was man will

runtimeexceptions in java sind halt beispielsweise stack overflow (rekursive methode falsch programmiert oder zu tief zb) oder array index out of bound

ich meine ich will nicht jedes mal wenn ich ein array benutze einen try catch block drum herum machen weil ich ja vielleicht in meiner for schleife die von 0 bis array.length geht auf einen ungültigen array index zugreife
oder um eine getter methode eine try/catch stackoverflow exception abfangen progbieren usw usw

dafür sind die halt gut, aber ich will schon einen benutzer dazu zwingen dass er eine LoadImageFile methode in einem zeichenprogramm oder so mit try/catch aufruft weil er wohl irgendwie etwas ausgeben möchte wenn der user versucht ein *.mp3 aufzumachen

runtime exceptions sind halt mehr so "assert" sachen, so wie

if(oh mein gott das darf niemals passieren)
    throw new NoobException("NOOB!"); //<- runtime exception

[tfa]

Gregor schrieb:

farbenkombination schrieb:

Gregor schrieb:

Gib mal ein Beispiel. Welches Framework meinst Du und was werden da für Exceptions geworfen.

Hibernate, wobei ich das nicht als gutes Framework bezeichnen würde, da daran schon viel zu oft was geändert wurde und man dann dauernd seinen Code ändern darf...

Und was für Exceptions betrifft das da? In welchem Zusammenhang werden die geworfen?

Alle Hibernate-Exceptions sind unchecked - und das ist auch gut so.
Als zweites großes Framework, das auf checked Exceptions verzichtet, ist Spring zu nennen.
Das Konzept der checked Exceptions in Java hat sich als nicht besonders brauchbar erwiesen. Deswegen sollte man sie nicht verwenden, wenn man selbst API entwirft.

[Gregor]

tfa schrieb:

Das Konzept der checked Exceptions in Java hat sich als nicht besonders brauchbar erwiesen. Deswegen sollte man sie nicht verwenden, wenn man selbst API entwirft.

Der Formulierung widerspreche ich einfach mal. Checked Exceptions haben genauso eine Berechtigung wie unchecked Exceptions. Aber ein anderes Anwendungsgebiet. Es gibt natürlich wenige Stellen, an denen checked Exceptions angebracht sind. Aber es gibt solche Stellen.

[DEvent]

Gregor schrieb:

tfa schrieb:

Das Konzept der checked Exceptions in Java hat sich als nicht besonders brauchbar erwiesen. Deswegen sollte man sie nicht verwenden, wenn man selbst API entwirft.

Der Formulierung widerspreche ich einfach mal. Checked Exceptions haben genauso eine Berechtigung wie unchecked Exceptions. Aber ein anderes Anwendungsgebiet. Es gibt natürlich wenige Stellen, an denen checked Exceptions angebracht sind. Aber es gibt solche Stellen.

Nenn doch bitte diese Stellen.

[Gregor]

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.

[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).