Wann normale Exception und wann Runtimeexception

[Gast 777]

Wann sollte man eigentlich eine RuntimeException werfen und wann eine normale Exception?

 

[tfa]

Die ursprüngliche Idee: "normale" Exceptions (sog. Checked Exceptions) müssen vom Programmierer explizit behandelt, also aufgefangen oder weitergeleitet werden. Wenn also der Programmierer gezwungen werden soll, auf eine Ausnahme zu reagieren, sind checked Exceptions zu verwenden.
Im Gegensatz dazu kann muss man sich um RuntimeExceptions nicht weiter kümmern (aber man kann). Sie werden einfach automatisch bis "ganz nach oben" durchgereicht und führen dann meist zum Programmabbruch und einer Fehlermeldung. Man sagt, RuntimeExceptions deuten auf Programmierfehler hin, wie NullPointer, ArrayIndexOutOfBounds, etc.

Die kurze Antwort: benutz RuntimeExceptions.
Checked Exception haben keinen großen Nutzen, manche Leute sagen sogar, sie seien dubios oder problematisch. Ein Problem ist, dass solche Exceptions häufig einfach verschluckt werden. Der Compiler meckert, also schnell ein try-catch drumherum machen (eine IDE macht das ja sogar auf Tastendruck), das die Exception auf stderr ausgibt, und schon ist das Problem erstmal behoben. Dass man sich damit eine vernünftige Fehlerbehandlung schwer macht, merkt man erst später. Außerdem wird der eigene Code durch die vielen try-catch-Blöcke nicht gerade übersichtlicher.

 

[Beni]

Die kurze Antwort: benutz RuntimeExceptions.
Checked Exception haben keinen großen Nutzen, manche Leute sagen sogar, sie seien dubios oder problematisch. Ein Problem ist, dass solche Exceptions häufig einfach verschluckt werden[...]

Also das finde ich jetzt ein bisschen zu einfach. Checked Exceptions haben durchaus ihre Berechtigung, mindestens überall dort wo man einen Fehler erwarten kann der vom Programm nicht beeinflusst werden kann.
Beispiel: man schreibt einen kleinen FTP-Client, der Code der sich mit dem Server verbindet kann nicht beeinflussen wann der Server abstürzt oder der User den Internetanschluss kappt. Da ist eine checked TimeOut- oder ServerMissing-Exception angebracht. Denn der Client sollte so eine Ausnahme wirklich behandeln, und nicht einfach abstürzen (eine RuntimeException kann ein Programm im schlimmsten Fall abschiessen, nämlich dann wenn sie nie behandelt wird. Für eine Checked-Exceptions ist das einges schwerer, da man checked-Exceptions öfters behandelt).

Was das Argument mit dem "verschlucken von Exceptions" angeht: Wenn der Programmierer zu doof ist zu programmieren, und derart elementare Fehler macht, wird das Projekt sowieso nix brauchbares... :bae:

[Edit: nette Links du da angibst tfa, da muss ich gleich mal ein bisschen rumstöbern :### ]

 

[tfa]

Also das finde ich jetzt ein bisschen zu einfach. Checked Exceptions haben durchaus ihre Berechtigung, mindestens überall dort wo man einen Fehler erwarten kann der vom Programm nicht beeinflusst werden kann.
Beispiel: man schreibt einen kleinen FTP-Client, der Code der sich mit dem Server verbindet kann nicht beeinflussen wann der Server abstürzt oder der User den Internetanschluss kappt. Da ist eine checked TimeOut- oder ServerMissing-Exception angebracht. Denn der Client sollte so eine Ausnahme wirklich behandeln, und nicht einfach abstürzen (eine RuntimeException kann ein Programm im schlimmsten Fall abschiessen, nämlich dann wenn sie nie behandelt wird. Für eine Checked-Exceptions ist das einges schwerer, da man checked-Exceptions öfters behandelt).

Klar soll das Programm die Exception fangen und eine Fehlermeldung ausgeben. Ebenso wie RuntimeExceptions (ganz oben) gefangen und eine Meldung ausgegeben wird. Keiner verlangt, das Programm abstürzen zu lassen.
Wo ist also der Unterschied zwischen der Behandlung einer checked und einer unchecked Exception? Es gibt keinen, nur dass man bei checked Exceptions noch viel mehr Code schreiben muss.
Die meisten checked Exceptions kann man sowieso nicht sinnvoll beheben, siehe FTP-Client oder der abgestürzte Server. Und wenn, finde ich, solltest du als Entwickler es besser entscheiden können, ob eine Exception sofort behandelt oder automatisch nach oben durchgereicht werden soll, als der Designer der FTP-Client-API oder des Server-Frameworks.

Ich glaube auch, dass checked Exceptions nicht mehr so akzeptiert werden. Beispielsweise war die HibernateException früher (vor vielen Jahren) noch checked. War ja auch klar, da die meisten HibernateExceptions ja von einer (checked) SQLException ausgelöst werden. Vor einiger Zeit hat man das dann aber auf eine RuntimeException umgestellt. Zuerst konnte ich das auch nicht verstehen. Aber mittlerweile bin ich überzeugt, dass das eine richtige Entscheidung war.

Was das Argument mit dem "verschlucken von Exceptions" angeht: Wenn der Programmierer zu doof ist zu programmieren, und derart elementare Fehler macht, wird das Projekt sowieso nix brauchbares... :bae:

Ich hab oft Code gesehen, wo das geschieht, wobei ich die Programmierer nicht als doof bezeichnen würde.
Selbst Bruce Eckel (Thinking in Java) gibt zu, sowas schon gemacht zu haben -- nicht aus Dummheit sondern wohl eher aus Unerfahrenheit: Does Java need Checked Exceptions?.

Bemerkenswert ist auch, dass Java die einzige Sprache mit dem Konzept der checked Exceptions ist. Selbst in C# hat man das verschmäht -- richtigerweise.

Noch ein Link zu dem Thema: Java's checked exceptions were a mistake

 

[Beni]

Klar soll das Programm die Exception fangen und eine Fehlermeldung ausgeben.

Wenigstens da sind wir uns einig :bae:

Ebenso wie RuntimeExceptions (ganz oben) gefangen und eine Meldung ausgegeben wird. Keiner verlangt, das Programm abstürzen zu lassen.
Wo ist also der Unterschied zwischen der Behandlung einer checked und einer unchecked Exception? Es gibt keinen, nur dass man bei checked Exceptions noch viel mehr Code schreiben muss.

Der Unterschied ist: der Compiler beschwert sich wenn du vergisst eine Checked Exception zu behandeln. Wenn du eine RuntimeException einfach vergisst, dann passiert halt nichts... bis der Fehler dann auftritt und du nachbessern darfst.

Bei der checked Exception zwingt dich der Compiler halt dich bewusst zu entscheiden was du willst, während das bei der RuntimeException im Hintergrund passiert. In einem hochdynamischen Programm - wie diejenigen deiner Beispiele - kann eine checked-Exception keine wichtigen Informationen mehr transportieren (weil alles mögliche passieren kann), aber je mehr man in die konstanteren Detail-Implementierung geht desto wichtiger wird es auf die verschiedenen Fehler zu reagieren.

Ich glaub schon, dass RuntimeExceptions "bequemer" sind (ich habe auch schon welche aus Bequemlichkeit angewendet), aber wenn du dann nicht eine gute Dokumentation hast und mehrere Entwickler an dem Projekt arbeiten, dann gehen diese RuntimeExceptions einfach vergessen.

Ich hab oft Code gesehen, wo das geschieht, wobei ich die Programmierer nicht als doof bezeichnen würde.
Selbst Bruce Eckel (Thinking in Java) gibt zu, sowas schon gemacht zu haben -- nicht aus Dummheit sondern wohl eher aus Unerfahrenheit: Does Java need Checked Exceptions?.

Ob ich aufrund meiner Doofheit oder aufgrund meiner Unerfahrenheit ohne Jacke in den Regen gehe macht keinen grossen Unterschied - ich werde trotzdem nass, kalt, schmutzig und krank. :wink:

Um auch noch einen Link einzuwerfen. Wenn man dem Vorschlag RuntimeExceptions zu nutzen folgt, muss man ein auch ein paar kleine Details beachten (die m.E. nicht minder mühsam als checked-Exceptions sind):
http://www.ibm.com/developerworks/java/library/j-jtp05254.html

If you do decide to use unchecked exceptions, you need to document this choice thoroughly, including documenting in Javadoc all the unchecked exceptions a method might throw. Johnson suggests making the decision between checked and unchecked exceptions on a package-by-package basis. When using unchecked exceptions, also remember that you may need to use try...finally blocked even when you are not catching any exceptions, so that you can perform cleanup actions such as closing database connections. With checked exceptions, we have try...catch to remind us to add a finally clause. With unchecked exceptions, we don't have that crutch to lean on.

 

[Gast]

die erste frage, die man sich bei der wahl einer exception stellen sollte ist folgende: kann ein entwickler auf den gerade aufgetretenen fehler sinnvoll reagieren.

die antwort lautet ganz klar ja, wenn der fehler mehr als wahrscheinlich durch umstände verursacht wird, auf die der entwickler keinen oder nur schwer einfluss nehmen kann.

die antwort lautet wahrscheinlich nein, wenn der fehler durch falsche verwendung eines stück codes verursacht wurde.

dafür, dass die entscheidung nicht immer so simpel ist, findet sich ein richtig schönes beispiel in den bekannten java methoden zum parsing von strings. als beispiel: Integer#parseInt(String)

die methode wirft eine unchecked exception, sollte der übergebene string keine zahl beinhalten.
dies widerspricht eigentlich der grundannahme. ein entwickler, der diese methode verwendet, wird sich schwertun, den string bereits vorher auf gültigkeit geprüft zu haben, denn genau das soll der parser eigentlich tun.
der entwickler der parsing methode wiederrum hat auf nummer sicher gespielt. er hat sich gedacht, dass es besser wäre, eine methode aussteigen zu lassen, bevor sie u.u. mit ungültigen zahlen weiterrechnet.

meiner ansicht nach war die entscheidung für eine unchecked exception in diesem fall schlecht. sinnvoller wäre es gewesen, der methode eine checked exception zu verpassen und es so jedem entwickler mehr aus deutlich zu machen, dass das parsing auch fehlschlagen kann und er sich um eine fehlerbehandlung gedanken machen muss.

ein positives beispiel ist die klasse java.net.URL. diese schmeisst nämlich sofort eine checked exception, wenn sie mit einer ungültigen URL initialisiert wird.

 

[tfa]

Ebenso wie RuntimeExceptions (ganz oben) gefangen und eine Meldung ausgegeben wird. Keiner verlangt, das Programm abstürzen zu lassen.
Wo ist also der Unterschied zwischen der Behandlung einer checked und einer unchecked Exception? Es gibt keinen, nur dass man bei checked Exceptions noch viel mehr Code schreiben muss.

Der Unterschied ist: der Compiler beschwert sich wenn du vergisst eine Checked Exception zu behandeln. Wenn du eine RuntimeException einfach vergisst, dann passiert halt nichts... bis der Fehler dann auftritt und du nachbessern darfst.

Das ist mir schon klar. Ich meinte auch nicht den syntaktischen Unterschied in der Sprache Java, sondern den logischen Unterschied in der Exceptionbehandlung, und der ist irrelevant. D.h. die meisten Exceptions müssen sowieso ganz nach oben durchgereicht werden. Warum soll ich "ganz unten" gezwungen werden, mich darum zu kümmern?

Außerdem finde ich es richtig gut, wenn Fehler auftreten (möglichst früh und möglichst hart) und ich nachbessern darf.

Bei der checked Exception zwingt dich der Compiler halt dich bewusst zu entscheiden was du willst, während das bei der RuntimeException im Hintergrund passiert.

Und dieser Zwang ist wie gesagt überflüssig.

In einem hochdynamischen Programm - wie diejenigen deiner Beispiele - kann eine checked-Exception keine wichtigen Informationen mehr transportieren (weil alles mögliche passieren kann), aber je mehr man in die konstanteren Detail-Implementierung geht desto wichtiger wird es auf die verschiedenen Fehler zu reagieren.

(Ich dachte, es war ursprünglich dein Beispiel, aber egal).
Aber es ist eine checked Exception, ich kann das ja nicht ändern - höchstens in eine RuntimeException kapseln und weiter werfen. Wenn es nötig ist, kannst du unchecked Exception ja ganz genauso durch try-catch auffangen und behandeln.

Ich glaub schon, dass RuntimeExceptions "bequemer" sind (ich habe auch schon welche aus Bequemlichkeit angewendet), aber wenn du dann nicht eine gute Dokumentation hast und mehrere Entwickler an dem Projekt arbeiten, dann gehen diese RuntimeExceptions einfach vergessen.

Dass Exceptions (Runtime oder nicht) dokumentiert werden müssen, halte ich für selbstverständlich. Was da jetzt die Anzahl der Entwickler mit zu tun hat, verstehe ich nicht.
Aber warum werden RuntimeExceptions vergessen? Die werden automatisch bis ganz nach oben geworfen und erzeugen eine Fehlermeldung. Wenn checked Exception vorzeitig behandelt werden (weil der Compiler das vorschreibt) ist die Gefahr größer, dass die verloren gehen.

Ein Beispiel, was mir vor 2 Wochen passiert ist: Eine Anwenderin beschwert sich, dass sie einen bestimmten Datensatz nicht anzeigen kann, obwohl dieser vorhanden ist. Es wird einfach nichts ausgegeben -- keine Fehlermeldung. Nach kurzer Suche habe ich herausgefunden, dass die betreffende Methode tatsächlich eine leere Liste zurückliefert, allerdings gab es auch einen Eintrag im Log. Der XML-Parser beschwerte sich über illegale Zeichen im Unicode-Dokument. Wahrscheinlich hatte jemand die Datenbank mit irgendwelchen bescheuerten Windows-Codepage-Buchstaben gefüttert. Diese Parse-Exception wurde brav aufgefangen und ordnungsgemäß geloggt. Wahrscheinlich war das sogar noch dokumentiert, allerdings hat die Anwenderin, die ihre Daten sehen will, davon nicht und ich auch nicht, weil der Fehler versteckt wurde und nicht automatisch zur Hotline geschickt wurde. Bei einer RuntimeException wäre dies nicht so leicht passiert. Und die Entwickler dieser Software (ein Fremdsystem, von dem wir Daten beziehen) sind sicherlich nicht dumm und nicht völlig unerfahren, trotzdem passieren solche Fehler.

Ich hab oft Code gesehen, wo das geschieht, wobei ich die Programmierer nicht als doof bezeichnen würde.
Selbst Bruce Eckel (Thinking in Java) gibt zu, sowas schon gemacht zu haben -- nicht aus Dummheit sondern wohl eher aus Unerfahrenheit: Does Java need Checked Exceptions?.

Ob ich aufrund meiner Doofheit oder aufgrund meiner Unerfahrenheit ohne Jacke in den Regen gehe macht keinen grossen Unterschied - ich werde trotzdem nass, kalt, schmutzig und krank. :wink:

Wenn du nur mit perfekten, hocherfahrenen Super-Programmieren zusammen arbeiten darfst, kann ich dich nur beneiden :wink:

 

[Beni]

Es ist Sonntag-Abend und ich will mich nicht streiten. Ausserdem hast du in (zu)vielen Belangen recht. :?
Deshalb beschränke ich mich auf die Teile die ich noch unbedingt los werden will.

Außerdem finde ich es richtig gut, wenn Fehler auftreten (möglichst früh und möglichst hart) und ich nachbessern darf.

Ich auch. Nur habe ich die Erfahrung gemacht, dass es auch Fehler gibt die sehr spät und fast nicht sichtbar sind... :bae:

Dass Exceptions (Runtime oder nicht) dokumentiert werden müssen, halte ich für selbstverständlich. Was da jetzt die Anzahl der Entwickler mit zu tun hat, verstehe ich nicht.

Dokumentation ist so eine Sache. Viele Leute haben sie extrem gerne. Sehr wenige machen sich wirklich die Mühe eine zu schreiben. Ich fürchte mit dem "selbstverständlich" bist du in einer Minderheit.

Was die Anzahl Leute angeht: wenn du mit deinen 3 Kollegen in einem Raum sitzt, kannst du den Kollegen auch kurz mal sagen wie sie deinen Code verwenden sollen. Die können auch nachfragen falls notwendig. Wenn du mit 500 Leuten die auf der ganzen Welt verstreut sind arbeitest wird das schwieriger. Und sei es nur, weil die Leute unterschiedlich erfahren sind. Mehr Leute = Mehr Koordination = Mehr Probleme.

(Ich dachte, es war ursprünglich dein Beispiel, aber egal).

Ich meinte deine Links mit "deinen Beispielen". Mein Beispiel ist nicht dynamisch, so ein ftp-client ist eher "trivial".

Wenn du nur mit perfekten, hocherfahrenen Super-Programmieren zusammen arbeiten darfst, kann ich dich nur beneiden :wink:

Ich hatte einmal die Gelegenheit, und das war schon eine tolle und produktive Zeit. Aber im Allgemeinen gibt es nichts zu beneiden. :lol:

 

[tfa]

Es ist Sonntag-Abend und ich will mich nicht streiten.

Ich auch nicht. Aber so ein bisschen Diskussion ist doch auch mal ganz nett (statt immer nur Newbies bei den Hausaufgaben zu helfen )

Eigentlich wollte ich nur sagen, dass es neben der althergebrachten Auffassung von Sun (checked/unchecked Exceptions) noch eine andere Sichtweise gibt. Welche man jetzt lieber hat, kann jeder für sich herausfinden.

Dass Exceptions (Runtime oder nicht) dokumentiert werden müssen, halte ich für selbstverständlich. Was da jetzt die Anzahl der Entwickler mit zu tun hat, verstehe ich nicht.

Dokumentation ist so eine Sache. Viele Leute haben sie extrem gerne. Sehr wenige machen sich wirklich die Mühe eine zu schreiben. Ich fürchte mit dem "selbstverständlich" bist du in einer Minderheit.

Ich geb zu, Anspruch und Wirklichkeit sind immer noch zu weit voneinander entfernt. Aber ich arbeite dran.

 

[???]

Aber führen unchecked Exceptions am Schluss nicht auch nur zu catch(Exception e)? Die die es mit checked Exceptions schon falsch gemacht haben, machen es doch mit unchecked bestimmt nicht besser.

 

[maki]

Hab das gerade gefunden, dachte es passt:
http://www.javaspecialists.eu/archive/Issue162.html

 

[SlaterB]

so, bevor ich den Text aus einem anderen Thread verwerfe, schreibe ich ihn hier noch mal rein,
keine Ahnung ob doppelt

Frage:

versuche mir gerade java privat anzueignen. dabei wird mir aber leider der unterschied zwischen geprüften und ungeprüften ausnahmen nicht ganz klar. ich habe zwar bsp. was eine ungeprüfte ausnahme ist, verstehe aber nicht warum diese nicht aufgefangen werden muss. ich lese immer nur das sie "typische" programmfehler darstellen und daher nicht aufgefangen werden müssen. aber bedeutet das nicht das jedesmal das programm beendet wird wenn eine solche ungeprüfte ausnahme auftritt? woran erkenn ich diese nun.

erkennbar daran, dass sie von RuntimeException oder Error erben,
am Namen selber (z.B. NullPointerException) nicht zu erkennen,

sinnvoll behandeln kann man die nicht,
in 10 Zeilen Code sind normalerweise 10 verschiedene Stellen für denkbare NullPointerException,
macht keinen Sinn, jeden einzelnen Programmschritt zu testen

das Programm würde dann beendet werden, korrekt in einfachen Fällen nur mit einer main,
in größeren Programmen ist es weniger dramatisch,
dort gibt es einzelne Thread, es kann nur einen Thread treffen,
oder bestimmte Codeabschnitte sind durch ein generelles 'fange alle Arten von Exceptions ab' geschützt,
in einer graphischen Oberfläche gilt dies z.B. für jedes Ereignis, jeden Button-Klick

auch in eigenen Programmen wird man an gewissen Stellen
'fange alle Arten von Exceptions ab' schreiben,
wenn man erstmal die Nachteile des Programmabbruchs kennengelernt hat
(und sie überhaupt Nachteile sind und nicht etwa Vorteile in dieser besonderen Situation)

wichtig dabei ist immer noch, dass das nur an wenigen Stellen zentral ungezielt passiert

 

[byte]

Aber es ist eine checked Exception, ich kann das ja nicht ändern - höchstens in eine RuntimeException kapseln und weiter werfen. Wenn es nötig ist, kannst du unchecked Exception ja ganz genauso durch try-catch auffangen und behandeln.

Der Witz ist, selbst Sun macht das an diversen Stellen genau so in der Java API. Ein schönes Beispiel ist Method#invoke(). Die Method wirft 3 checked Exceptions, was mal elendig nervig ist, die jedes mal zu fangen. Ich habe schon einige Stellen in der Java API gesehen, wo die Behandlung dieser 3 Exceptions jeweils identisch ist, und zwar so: throw new InternalError(e). :roll:

Ich seh das so wie tfa und viele der großen Java-Frameworks offenbar auch (Spring, Hibernate, ...): Checked Exceptions fördern Boilerplate Code.