Checked Exceptions werden zur Anzeige von Fehlerzuständen benutzt, auf die "irgendwie sinnvoll" reagiert werden kann. Unchecked Exceptions werden benutzt, um einem Programmierer anzuzeigen, dass er einen Fehler gemacht hat.
Grad neulich gab es hier über checked vs unchecked eine Diskussion. Endlich einer, der das genauso sieht wie ich!
Ich tendiere inzwischen eher dazu, immer unchecked Exceptioins zu werfen.
...oder doch nicht
Meine Meinung: Wenn irgendwo ein Fehler auftreten kann, gegen
dessen Auftreten du zur Laufzeit nichts tun kannst, dann wirf eine checked Exception. Selbst wenn dir am Ende nix übrig bleibt außer die Anzeige einer Fehlermeldung mit Programm-Terminierung. Damit wird der Aufrufer gezwungen, auf den Fehler - sollte er eintreten - zu reagieren. Beispiel: Operationen auf dem Dateisystem. Du kannst als Programmierer nicht verhindern dass ein User evtl. die nötigen Rechte für das Lesen/Schreiben einer Datei nicht hat oder ob ihm grad die Festplatte durchbrennt.
Wie schon richtig gesagt stehen solchen Fehlern die Programmierfehler entgegen: Fehler, die auftreten weil was in deiner Programmlogik nicht stimmt. Bekanntestes Beispiel: NullPointerException. Die sind nicht checked, weil sie auch gar nicht auftreten, wenn du alles richtig gemacht hast.
Aus diesem Grund tendiere
ich dazu, unchecked Exceptions zu vermeiden. Ich würde ein unchecked auch niemals abfangen, denn sie sollte gar nicht auftreten. Wenn ich aber davon ausgehe dass sie manchmal auftreten kann, ohne dass ich etwas dagegen tun könnte, dann mach ich sie checked damit mich der Compiler netterweise drauf aufmerksam macht und ich eine Behandlung nicht vergesse, was sich dann "Bug" nennen würde. (Eben weil die Fehler vllt bei dir nicht auftreten, bei anderen schon).
@TO: Man sollte das Wort "Fehler" nicht zu genau nehmen.. Exceptions stellen nicht unbedingt "Fehler" dar. Deswegen heißt es Exception und nicht Error. Es sind Ausnahmesituationen, auf die gesondert reagiert werden muss. Wenn man selbst Exceptions wirft dann plant man ja nicht, einen Fehler zu integrieren. Man möchte wie nillehammer auch schon richtig sagte lediglich die Info über eine spezielle Situation weiterreichen. Exceptions sind ein wesentlicher Bestandteil von OOP-Software, auch von einer die 100% korrekt läuft und nicht einen einzigen Fehler aufweisen kann.
@nillehammer
Du widersprichst dich doch irgendwie. Warum schmeißt du Exceptions die du selbst als Programmierfehler kategorisierst? Wäre es da nicht naheliegender den Fehler zu beheben statt eine Exception zu werfen?
Ich habe schon im besagten Topic mitbekommen dass das der Trend tatsächlich hin zu unchecked Exceptions geht, ich verstehe aber noch immer nicht warum. Ich verstehe, dass manche checked Exceptions aus der API nerven, weil man dagegen gar nix tun kann oder will. z.B. bei Thread.sleep, wenn ich gar kein interrupt beabsichtige, ja diese try-catch-Blöcke nerven. Aber das ist imho eine Design-Fehlentscheidung aus der API, nicht grundsätzlich ein Manko der checked Exceptions. Ich verstehe nicht, warum man selbst auf checked Exceptions verzichten will, wogegen man in der Tat was tun kann. Ist doch einfach sicherer?! Die unchecked Exceptions fangt ihr ja auch ab, also wo is der Unterschied, außer das man's dummerweise vergessen kann? Ich will btw nicht das Thema umlenken, falls das jetzt nicht philosphisch werden soll. Aber ich würd's einfach gern begreifen, irgendwas muss ja an diesem Trend dran sein, aber ich seh's nicht. Alle sagen checked Exceptions waren eine Fehlentscheidung. Ich finde unchecked Exceptions waren eine Fehlentscheidung. Ich fang doch nix ab was aus kaputtem Code entsteht, ich fixe den Code.
