Sinn von RuntimeExceptions?

[hdi]

Hey Jungs..

ich wollte gerade jmd erklären wofür genau Exceptions da sind und wie man sie benutzt. Dabei musste ich feststellen dass mir die RuntimeExceptions (also unchecked) selbst ein Rätsel sind.

Erstmal hoffe ich dass ich zumindest die checked Exceptions verstehe: checked Exceptions machen Sinn da man zur Compile-Zeit sicherstellt dass auf mögliche kritische Situationen (zB falsche User-Eingabe) reagiert wird. Und hauptsächlich ist der Vorteil davon einfach nur dass ich durch das Exception Handling entscheiden kann, wo genau man auf so eine Situation reagiert (Weiterreichen per throw - ich möchte in der Methode nicht konkret entscheiden wie reagiert wird, u.U. kann ich das dort gar nicht)

Ich hoffe das hab ich richtig verstanden?

Aber jetzt zu unchecked: Was soll das? Es wird nicht sichergestellt dass man darauf reagiert, man weiss oft gar nicht dass dieser Fehler auftreten kann, und alles was es tut ist ne Message anzuzeigen und den Thread zu killen. Letztendlich läuft meine Frage auf folgendes hinaus:

Warum

throw new RuntimeException();

statt:

System.err.prnitln("Fehler blablabla");
System.exit(-1); // bzw nur den Thread killen

Macht doch das gleiche? Und der Aufrufer hat doch eh keine Ahnung bei ner RuntimeException dass sie auftreten kann, wenn er nicht zufällig in den Source schaut??
Also ich glaub ich hab das mit den Exceptions noch nicht wirklich verstanden.. benutz es wie gesagt selber eig. gar nicht.

lg

 

[rambozola]

Dabei musste ich feststellen dass mir die RuntimeExceptions (also unchecked) selbst ein Rätsel sind.

Hm tatsächlich? Ich hab nie verstanden wozu checked Exceptions gut sein sollen, die gehören nämlich abgeschafft!

 

[hdi]

Aha, also gegensätzliche Meinung, interessant. Wieso findest du sie gehören abgeschafft? Ich persönlich sehe darin schon Sinn: Wenn in meinem Code etwas schief gehen kann und es kann von Anwendung zu Anwendung unterschiedlich sein, wie man darauf reagieren soll, habe ich durch checked Exceptions die Möglichkeit, in meiner API zu sagen: Pass auf was du tust, x und y kann hier in die Hose gehen, überleg dir was du in so einem Fall machst!

Ich sehe in den unchecked keinen Sinn, weil sie nicht auf sich aufmerksam machen und nix weiter darstellen als eine Meldung in der Konsole (mit anschliessendem Thread-Kill).

Die Diskussion ist eröffnet

 

[tfa]

Ich finde auch, dass checked Exceptions mehr Nachteile als Vorteile mit sich bringen.
Ein bisschen was dazu habe ich hier zusammengeschrieben: http://www.java-forum.org/blogs/tfa/79-exceptions-faq.html

 

[miwoe]

Hum, ich seh das anders.

(Fast) Jeder Fehler ist behebbar. Nur ist es manchmal sehr aufwändig zu programmieren Ganz besonders:

Was soll aber passieren, wenn IOException in einem Server-Prozess fliegt, etwa, weil die Konfigurationsdatei
der Servers nicht gelesen werden kann oder kein freier Festplattenspeicher mehr verfügbar ist. Diese
Situationen sind nicht behebbar. Es bleibt einem nichts anderes übrig, als die Exception zu loggen, ggf. den
Administrator zu verständigen und das Programm zu beenden.

Warum soll das weniger behebbar sein? Man muss dem Server "nur" mit der Richtlinie ausrüsten, die auch der menschliche Benutzer verwenden würde, wie z.B. eine Default-Konfiguration wählen, Festplattenspeicher frei machen, etc. In Hochverfügbarkeitsumgebungen kann ich dir garantieren, dass dieser Fehler behandelt werden wird.

Finde ich sehr schlechtes Beispiel oder schlechte Argumentation. Wenn du sagen willst, dass die Exception ohnehin nur beim Serverstart geworfen wird, bei dem folglich dann die Entwickler den Fehler behandeln sollen und nicht der aktive Thread, dann geb ich dir recht. Wenn jedoch die Konfiguration regelmäßig neu eingelesen wird, wird sie garantiert behandelt.

Andererseits stimme ich zu, dass ein Compiler dennoch kompilieren können sollte, wenn eine Check Exception nicht abgefangen wird. Wenn der Entwickler nicht will, dann will er eben nicht. Entwicklungsumgebungen sollten dann lediglich dazu raten, eine Behandlung zu schreiben.

Nervig ist halt nur sowas:

try {
...
catch (Exception e) {
  // Todo: Auto-generated catch clause
}

 

[musiKk]

Aber jetzt zu unchecked: Was soll das? Es wird nicht sichergestellt dass man darauf reagiert, man weiss oft gar nicht dass dieser Fehler auftreten kann, und alles was es tut ist ne Message anzuzeigen und den Thread zu killen.

Ganz kurz: Weil man auch nicht darauf reagieren soll; unchecked Exceptions sollen Programmierfehler darstellen. IOException kann man nicht beeinflussen, aber bei einer NPE fehlt halt schlicht und ergreifend der null-Check, etc.

So wars jedenfalls geplant (oder zumindest interpretiert). Wie die anderen schreiben geht die Entwicklung eher weg von den checked Exceptions.

 

[Marco13]

Ist vielleicht ein bißchen... "flach", das Besipiel, aber ... sowas wie eine NullPointerException kann ja schlecht checked sein.... !? Und die können ja praktisch überall auftreten... Ich finde auch, dass Checked Exceptions manchmal "nervig" sein können. Wer schonmal mit RMI zu tun hatte, oder versucht hat, mit Reflection eine Methode aufzurufen, und sich dabei mit... 5 oder 6 Checked Exceptions für einen Aufruf rumschlagen durfte, weiß, was ich meine. Aber sie gleich ganz abschaffen...? Hm. Eine definitive Meinung habe ich nicht. Es gibt wohl kein silver bullet.

(Geek And Poke: Simply Explained: Checked Exceptions )

 

[The_S]

Ui ... das Lieblingsthema, das grundsätzlich für ein paar feuchte Augen hier im Forum sorgt .

@hdi einfach mal im Forum danach suchen. Müsste schon unzählige Threads zu dem Thema geben, in denen alle Vor- und Nachteile der jeweiligen Exceptions bis ins Detail geklärt wurden.

 

[tfa]

Hum, ich seh das anders.
Warum soll das weniger behebbar sein? Man muss dem Server "nur" mit der Richtlinie ausrüsten, die auch der menschliche Benutzer verwenden würde, wie z.B. eine Default-Konfiguration wählen, Festplattenspeicher frei machen, etc. In Hochverfügbarkeitsumgebungen kann ich dir garantieren, dass dieser Fehler behandelt werden wird.

Nach meiner Definition ist die Serverkonfiguration zwingend nötig, um den Server überhaupt erstmal zu starten. Keine Konfiguration->Fataler Fehler. Warum sollte man den Fehler verstecken, indem man aufwendig eine Krücke drum rum programmiert? Ebenso die volle Festplatte. Soll das Programm zufällig irgendwelche Dateien löschen?

Finde ich sehr schlechtes Beispiel oder schlechte Argumentation. Wenn du sagen willst, dass die Exception ohnehin nur beim Serverstart geworfen wird, bei dem folglich dann die Entwickler den Fehler behandeln sollen und nicht der aktive Thread, dann geb ich dir recht.

So meinte ich das.

Wenn jedoch die Konfiguration regelmäßig neu eingelesen wird, wird sie garantiert behandelt.

Behandelt wird natürlich jeder Fehler. Aber dazu braucht man keine checked Exceptions. RuntimeExceptions kann man genauso fangen und behandeln.

Andererseits stimme ich zu, dass ein Compiler dennoch kompilieren können sollte, wenn eine Check Exception nicht abgefangen wird. Wenn der Entwickler nicht will, dann will er eben nicht. Entwicklungsumgebungen sollten dann lediglich dazu raten, eine Behandlung zu schreiben.

Dann wären es keine checked Exceptions mehr. Genau das wäre wünschenwert (obwohl es nie passieren wird).
Fakt ist nunmal, dass andere Sprachen dieses Konzept bewusst nicht umsetzen und sogar viele bekannte Java-Frameworks nur noch RuntimeExceptions verwenden.

 

[Tomate_Salat]

ich MAG checked Exceptions. Solange sie bedacht und sinnvoll geworfen werden. Ich mags nur nicht, wenn eine Klasse diese bereits im Konstruktor wirft :-!. Ich halte Sie aber dennoch für sinnvoll, da dem Benutzer der Klasse gleich mitgeteilt wird, an welchen Stellen probleme auftauchen können. Trotzdem sollte man mit diesen Sparsam umgehen. UncheckedExceptions mag ich nicht wirklich und dass Programmierer selbst RuntimeExceptions schmeisen finde ich ehrlich gesagt ne katastrophe!

Wenn ich in meinem Code eine Exception einbaue dann hat das schon seine Gründe: a) Die komponente ist nur unter Gewissen Bedinungen verwendbar und b) ich informiere von vorne rein, dass man den Code nur bestimmt anwenden kann und dass es zu fehler x oder y führen kann, wenn man nicht ordnungsgemäß mit umgeht!

 

[maki]

Checked Exceptions sind eine Krankheit die abgeschafft gehört

UncheckedExceptions mag ich nicht wirklich und dass Programmierer selbst RuntimeExceptions schmeisen finde ich ehrlich gesagt ne katastrophe!

Katastrophe?
Nein, sondern ein Mittel um mit der Krankheit checked Exceptions klarzukommen.

Die Diskussion checked vs unchecked Exceptions ist schon lange geführt worden, mit dem Egebniss, dass checked Exceptions vermieden werden sollten.

 

[Landei]

Checked Exceptions sind krank, und das lässt sich ganz einfach begründen: Angenommen ich habe ein Interface für das Einlesen einer Konfiguration. Implementierungen dieses Interfaces können nun die Konfiguration aus einer Datei, einer Datenbank, einem Webservice oder sonstwo auslesen. In jedem Fall können andere checked Exceptions auftreten, ich habe aber keine andere Möglichkeit, sie ans Interface weiterzuleiten, als irgendeinen vorgegebenen Exception-Typ zu verwenden und die checked Exceptions hübsch zu verpacken, weil ich ja nicht voraussehen kann, welche checked Excpetions mir um die Ohren fliegen werden. Checked Exceptions zum Teil der Methoden-Signatur zu machen, ist einfach pervers. Die einzige Möglichkeit, die ich sehe, um das zu fixen, wäre einer Erweiterung von Generics, so dass ich schreiben könnte:

interface ConfigReader<Ex extends Exception> {
   public Config read(String identifier) throws Ex;
}

class FileConfigReader implements ConfigReader<FileNotFoundException> {
   public Config read(String identifier) throws FileNotFoundException {
      //do the magic
   }
}

 

[Noctarius]

Die Generics Erweiterung klingt gut, aber zu deinem "Nachteil":
Ich will einen Parser bauen, so dafür nehm ich eine ParserFailedException. Jetzt könnte die Datei, welche ich parsen will, nicht existieren. Ergo würde eine IOException fliegen.

Die Frage ist in diesem Fall was ich haben will:
1. Ich will einfach nur eine Exception die ich dem User zeigen kann oder
2. Mich interessiert nur indirekt was wirklich passiert ist (als Coder z.B.) aber dem User will ich sagen, dass der Parser nicht arbeiten konnte oder
3. Ich will einfach nur dafür sorgen, dass wenn der Parser nicht kann (immer wenn eine ParserFailedException kommt) soll er was anderes versuchen.

Ich könnte alle 3 Fälle auch über [c]throws Exception[/c] abfangen aber ob das schöner ist. Auch an diesem Punkt würde die Generics-Erweiterung nicht viel nützen, weil [c]Ex extends Exception[/c] genau das selbe Problem machen würde wie Runtime Exceptions. Ich wüsste nicht was ich abfangen muss. Es kann schließlich nahezu alles (außer Error und Throwable) fliegen.

 

[byte]

Warum soll das weniger behebbar sein?

Es geht nicht darum, ob etwas behebbar (checked) oder unbehebbar (unchecked) ist. Es geht darum, dass es meistens am sinnvollsten ist, Exceptions nur an einer oder wenigen Stellen zu behandeln (nämlich in einem Exception Handler). Und dafür sind Checked Exceptions eben nicht geeignet, denn die MUSS man sofort behandeln. Unchecked Exceptions hingegen müssen nicht behandelt werden, sondern fliegen automatisch weiter und werden spätestens vom Uncaught Exception Handler des Threads behandelt.

 

[byte]

Ganz kurz: Weil man auch nicht darauf reagieren soll; unchecked Exceptions sollen Programmierfehler darstellen. IOException kann man nicht beeinflussen, aber bei einer NPE fehlt halt schlicht und ergreifend der null-Check, etc.

Warum sollte man nicht auf unchecked Exceptions reagieren? Man kann sie genauso behandeln wie checked Exceptions. Man muss es aber nicht. Das ist der einzige Unterschied.

Ich fange sehr häufig RuntimeExceptions und behandele sie.

 

[byte]

Wenn ich in meinem Code eine Exception einbaue dann hat das schon seine Gründe: a) Die komponente ist nur unter Gewissen Bedinungen verwendbar und b) ich informiere von vorne rein, dass man den Code nur bestimmt anwenden kann und dass es zu fehler x oder y führen kann, wenn man nicht ordnungsgemäß mit umgeht!

Und wozu brauchst Du dafür Checked Exceptions? Was ist, wenn der Entwickler genau weiss, wie Dein Code zu verwenden ist. Dann muss er trotzdem die Checked Exceptions behandeln, obwohl sie faktisch nie auftritt -> Boilerplate Code!

 

[Landei]

Um mein Beispiel um die Benutzer-Seite zu erweitern und ein bisschen neue Syntax zu erspinnen:

class Client {
...
  Config config = null;
  try<Ex extends Exception> {
     ConfigReader<Ex> configReader = ConfigReaderFactory.getConfigReader(); 
     config = configReader.read();
  } catch (Ex ex) {
      ExceptionHandler<Ex> exceptionHandler = ExceptionTools.findHandler(ex);
      if(exceptionHandler != null) {
          exceptionHandler.handle(ex); 
      } else {
         ex.printStackTrace();
         System.exit(0x29A); 
      }
  }
  ...

Aber das zeigt schon, dass es schwierig würde, damit vernünftig umzugehen...

 

[Noctarius]

Dann kann ich aber auch gleich Exception ansich abfangen und an einen entsprechenden ExceptionHandler weiterreichen, mach ich Heute an manchen Punkten schon so.

 

[byte]

interface ConfigReader<Ex extends Exception> {
   public Config read(String identifier) throws Ex;
}

class FileConfigReader implements ConfigReader<FileNotFoundException> {
   public Config read(String identifier) throws FileNotFoundException {
      //do the magic
   }
}

Das sehe ich jetzt aber nicht wirklich als Problem von Checked Exceptions. Man kann sich ja problemlos für so eine Config Reader API eine ConfigReaderException als Basis-Exception definieren und dort dann alle möglichen (implementierungsspezifischen) Exceptions wrappen.

Oder gibt es ein ungeschriebenes Gesetz, dass sobald eine Datei nicht gefunden wurde, umbedingt immer eine FileNotFoundException fliegen muss? Hier könnte man einfach eine ConfigReaderException definieren und davon eine ConfigNotFoundException ableiten. Diese könnte ja problemlos eine mögliche FileNotFoundException wrappen.

Wer mal eine schöne Exception Hierarchie sehen will, der gucke sich org.springframework.dao.DataAccessException + Ableitungen an. Natürlich alles Unchecked Exceptions.

 

[Tomate_Salat]

Und wozu brauchst Du dafür Checked Exceptions? Was ist, wenn der Entwickler genau weiss, wie Dein Code zu verwenden ist. Dann muss er trotzdem die Checked Exceptions behandeln, obwohl sie faktisch nie auftritt -> Boilerplate Code!

Und was ist wenn nicht?! Checked Exceptions haben den Vorteil, dass man einfach auf Sie reagieren kann. Ich verwende z.B. eine eigens entwickelte Console für mein aktuelles Projekt. Wenn jz soetwas auftritt wie: "Server-url" falsch, dann kann ich schon an der Exception die evtl. geschmissen wird sehen, wo das Problem mal entstehen kann. Ich brauche mir keine ellen-lange Exception ausgeben lassen, wo im prinzip drinn steht: "Url nicht korrekt". Da kann ich eleganter drauf reagieren und mir in die Console schreiben lassen: URL nicht gefunden und dann einen export der Konsoleneinträge machen lassen. Unchecked Exceptions kommen i.d.R. eher unerwartet und werden (noch) nicht von meiner Console abgefangen + registriert.
Checked Exceptions sind mir da schon lieber, auch wenn der try-catch-block einem auf die nerven gehen kann.

 

[maki]

Und was ist wenn nicht?! Checked Exceptions haben den Vorteil, dass man einfach auf Sie reagieren kann.

Checked Exceptions haben den Nachteil, dass man auf sie reagieren muss, egal ob man sie sinnvoll behandeln kann oder nicht..

Dann führen sie noch zu "leaky abstractions", zu überflüssigem Code (try/catch ohne Grund bzw. Sinn), alles in allem sind sie eine schlechte Sache, ist aber alles schon x-mal gesagt worden, keien andere Sprache hat den Fehler der checked Exceptions nachgemacht, aus gutem Grund.

Der einzige mögliche Vorteil von checked Exceptions ist eben, dass der Entwickler vergessen könnte seine Exceptions in die JavaDoc zu schreiben mit unchecked Exceptions, dafür versaut man sich aber das Interface (leaky abstraction).

 

[byte]

Und was ist wenn nicht?! Checked Exceptions haben den Vorteil, dass man einfach auf Sie reagieren kann....

Du kannst genauso einfach auf Unchecked Exceptions reagieren wie auf Checked Exceptions. Du musst einfach nur in die Javadoc gucken, was unter @throws aufgeführt ist. In einer sauberen Javadoc sind dort Unchecked Exceptions genauso beschreiben wie Checked Exceptions.

Oder dachtest Du, man muss solange warten, bis sie das erste Mal fliegen, um auf Unchecked Exceptions zu reagieren?

 

[tfa]

Checked Exceptions haben den Vorteil, dass man einfach auf Sie reagieren kann.

Checked Exceptions haben den Nachteil, dass man einfach auf Sie reagieren muss.

Auch wenn man sie nicht behandeln kann. Die Entwickler des API, das checked Exceptions vorschreibt, kann gar nicht wissen, ob sein Client (also du) die Ausnahme behandeln kann. Also sollte er es auch nicht vorschreiben.

Ich behaupte, 95% aller gängigen Exception aus der Standard-API lassen sicht nicht an Ort und Stelle beheben. Alles was mit SQLException, RemoteException, alle Exceptions, die mit Reflection zu tun haben, und auch viele IOExceptions. Alle mit try-catch oder throws abhandeln zu müssen ist nutzlos und fehleranfällig.

Ich verwende z.B. eine eigens entwickelte Console für mein aktuelles Projekt. Wenn jz soetwas auftritt wie: "Server-url" falsch, dann kann ich schon an der Exception die evtl. geschmissen wird sehen, wo das Problem mal entstehen kann. Ich brauche mir keine ellen-lange Exception ausgeben lassen, wo im prinzip drinn steht: "Url nicht korrekt". Da kann ich eleganter drauf reagieren und mir in die Console schreiben lassen: URL nicht gefunden und dann einen export der Konsoleneinträge machen lassen. Unchecked Exceptions kommen i.d.R. eher unerwartet und werden (noch) nicht von meiner Console abgefangen + registriert.

Wenn du in deinem geschlossenen Programm eine eigene checked Exception definierst, über die du volle Kontrolle hast, mag das OK für dich sein. Dieser kleine Vorteil kann aber den grundsätzlichen Nachteil nicht aufheben.

Checked Exceptions sind mir da schon lieber, auch wenn der try-catch-block einem auf die nerven gehen kann.

try-catch kannst du auch um RuntimeExceptions machen, wenn es nötig ist. Man muss seinen Code sowieso bezüglich Fehlerhandlung testen, am besten durch Unit-Tests. Der Behandlungszwang von checked Exceptions gaukelt einem nur Sicherheit vor.

 

[Landei]

Das sehe ich jetzt aber nicht wirklich als Problem von Checked Exceptions. Man kann sich ja problemlos für so eine Config Reader API eine ConfigReaderException als Basis-Exception definieren und dort dann alle möglichen (implementierungsspezifischen) Exceptions wrappen.

Oder gibt es ein ungeschriebenes Gesetz, dass sobald eine Datei nicht gefunden wurde, umbedingt immer eine FileNotFoundException fliegen muss? Hier könnte man einfach eine ConfigReaderException definieren und davon eine ConfigNotFoundException ableiten. Diese könnte ja problemlos eine mögliche FileNotFoundException wrappen.

Sag ich ja: Da sowas nicht geht, muss man wrappen. Wrapped man, muss man im Nachhinein rausfinden, was drinsteckt. Hat man eine "normale" Exception, kann man über verschiedene catch-Blöcke den richtigen Typ herausfiltern. Hat man eine gewrappte Exception, geht das nicht mehr. Damit ist der ganze Sinn von checked Exceptions meiner Meinung nach für'n Dutt. Hinzu kommt, dass ja mit einmaligen Wrappen nicht Schluss ist: Ich habe öfter mit Sachen zu tun wie einer RuntimeException, in der eine RemoteException steckt, in der eine CheckInException steckt, in der eine BusinessObjectNotFoundException steckt, in der eine NullPointerException steckt. Was soll der Blödsinn?

 

[Tomate_Salat]

Du kannst genauso einfach auf Unchecked Exceptions reagieren wie auf Checked Exceptions. Du musst einfach nur in die Javadoc gucken, was unter @throws aufgeführt ist. In einer sauberen Javadoc sind dort Unchecked Exceptions genauso beschreiben wie Checked Exceptions.

Oder dachtest Du, man muss solange warten, bis sie das erste Mal fliegen, um auf Unchecked Exceptions zu reagieren?

Für Java-Doc alles nachzuschaun bin ich zu faul :rtfm::autsch:, dann lieber en try-catch-block mehr.

Nö mir ist schon klar, dass man auf die reagieren kann, auch wenn sie noch nicht geschmissen wurden. Aber es ist leichter sie zu übersehen!

Checked Exceptions haben den Nachteil, dass man einfach auf Sie reagieren muss.

Auch wenn man sie nicht behandeln kann. Die Entwickler des API, das checked Exceptions vorschreibt, kann gar nicht wissen, ob sein Client (also du) die Ausnahme behandeln kann. Also sollte er es auch nicht vorschreiben.

Ist wohl besser, wenn sie ihm einfach das Programm killen ;-)

Ich behaupte, 95% aller gängigen Exception aus der Standard-API lassen sicht nicht an Ort und Stelle beheben. Alles was mit SQLException, RemoteException, alle Exceptions, die mit Reflection zu tun haben, und auch viele IOExceptions. Alle mit try-catch oder throws abhandeln zu müssen ist nutzlos und fehleranfällig.

Wenn der SQL falsch ist... Auch wenn man sie nicht sofort beheben kann, muss man sie beheben. Ich finde nachwievor es nicht verkehrt, den Entwickler auf kritische Stellen hinzuweisen. Wenn man z.B. einen falschen SQL sendet, dann kann das a) am Programm oder b) am Benutzer liegen. Ist B) der fall, dann muss das ganze nicht dokumentiert werden und geht den Entwickler letztendlich nichts mehr an und der Benutzer kann darauf hingewiesen werden. Im falle a, solltle das Dokumentiert und gesendet werden. Klar sollte man Eingaben immer Kontrollieren, aber einen SQL auf seine komplette richtigkeit prüfen?! Da ist ein try-catch wohl wesentl. kürzer.

try-catch kannst du auch um RuntimeExceptions machen, wenn es nötig ist. Man muss seinen Code sowieso bezüglich Fehlerhandlung testen, am besten durch Unit-Tests. Der Behandlungszwang von checked Exceptions gaukelt einem nur Sicherheit vor.

Sind wir einer Meinung, aber auch hier musst du try-catch einsetzen um auf die RuntimeExceptions zu reagieren. Wer noch nie etwas von RuntimeExceptions gehört hat, dem gaukeln Sie bestimmt Sicherheit vor, allerdings helfen Sie auf kritische und anfällige Stellen zu reagieren.

Eine Möglichkeit einzubauen, solche Exceptions nicht zu behandeln halte ich für viel gefährlicher. Vor allem Anfänger werden sich wohl dann noch kaum um diese kümmern und sagen: verwerfen wir sie einfach mal. Manche Exceptions mögen sinnlos sein, weil sie z.B. auf den späteren Programmverlauf vllt wirklich kaum bis gar keine auswirkung haben. Aber das ist meiner Meinung nach die Minderheit.

Mögliches Fehlverhalten gehört einfach behandelt, auch wenn man das Problem vllt nicht lösen kann, kann man das Programm dennoch in eine andere Richtung lenken. Alles andere ist für mich einfach schlechter Programmierstil

 

[bygones]

Für Java-Doc alles nachzuschaun bin ich zu faul :rtfm::autsch:, dann lieber en try-catch-block mehr.

schlechter programmierstil erlaubt keine unsinnigen sachen... das Problem ist wenn du zu faul bist etwas zu tun und eine API bereitstellst die andere nutzen wollen / muessen, sind sie auf die Dinger die deiner Faulheit zu Grunde liegen angewiesen... und das ist mehr als unschoenes (nett formuliert) programmieren.

ansonsten stimme ich den meisten hier zu: checked exceptions sind ne krankheit.

Mögliches Fehlverhalten gehört einfach behandelt, auch wenn man das Problem vllt nicht lösen kann, kann man das Programm dennoch in eine andere Richtung lenken. Alles andere ist für mich einfach schlechter Programmierstil

und was hat das mit (un)checked Exceptions zu tun ? Natuerlich gehoeren Fehlerfaelle behandelt, natuerlich gehoeren sie geloest wenn moeglich... dafuer aber checked Exceptions einzusetzen ist nun mal ein ziemlich falscher weg

 

[tfa]

@Tomate_Salat

Ich glaube wir haben hier ein grundlegendes Missverständnis. Natürlich werden Exceptions nicht einfach verschluckt, sondern irgendwann behandelt (ich hätte beheben statt behandeln schreiben sollen). Aber bitte an einer zentralen Stelle in einem ExceptionHandler, der Fehler loggt oder anzeigt und das Programm ggf. in einen Fail-Safe-Zustand bringt. Und nicht an 1000 Stellen über den Code verstreut, wie das bei checked Exceptions nötig wäre.
Für eine angemessene Behandlung reichen aber immer RuntimeExceptions aus. Eine angemessene Behebung ist selten möglich - meine Erfahrung.

Klar sollte man Eingaben immer Kontrollieren, aber einen SQL auf seine komplette richtigkeit prüfen?! Da ist ein try-catch wohl wesentl. kürzer.

Hm, also meine Anwender geben keine SQL-Query ein. SQLExceptions gibt es eher, wenn keine DB-Connection zu stande kommt, oder ein Timeout fliegt oder irgendeine View nicht vorhanden ist usw.

Eine Möglichkeit einzubauen, solche Exceptions nicht zu behandeln halte ich für viel gefährlicher. Vor allem Anfänger werden sich wohl dann noch kaum um diese kümmern und sagen: verwerfen wir sie einfach mal.

Gerade das passiert doch bei checked Exceptions, die Anfänger einfach verschlucken, weil sie gezwungen werden, sie zu fangen! RuntimeExceptions werden nicht verworfen, wenn man sie nicht fängt. Sie fliegen bis ganz nach oben und landen im ExceptionHandler.

 

[Tomate_Salat]

schlechter programmierstil erlaubt keine unsinnigen sachen... das Problem ist wenn du zu faul bist etwas zu tun und eine API bereitstellst die andere nutzen wollen / muessen, sind sie auf die Dinger die deiner Faulheit zu Grunde liegen angewiesen... und das ist mehr als unschoenes (nett formuliert) programmieren.

Sehe ich nicht als schlechten Programmierstil. Wenn etwas unklar ist, schau ich natürlich in die Doc. Ich sehe das ganz anderster: Wenn der Entwickler RuntimeExceptions für sein vorhaben missbraucht, dann werden mir die in der Entwicklerumgebung "verheimlicht". Ist dazu die Api evtl. dazu nicht richtig Dokumentiert, habe ich als Entwickler nochmal ein Problem mehr! Das setzt also vorraus das ich eine gescheite Dokumentation habe. Wenn ich sicher gehen will, müsste ich (falls möglich!) noch den anderen code durchgehen?!

RuntimeException is the superclass of those exceptions that can be thrown during the normal operation of the Java Virtual Machine.

Dabei sollte es bleiben, alles andere ist in meinen Augen schlechter Programmierstil. Wenn man diese zweckenfremdet, dann sollte man einen guten Grund haben. Ansonsten sollten normale Exceptions her

und was hat das mit (un)checked Exceptions zu tun ? Natuerlich gehoeren Fehlerfaelle behandelt, natuerlich gehoeren sie geloest wenn moeglich... dafuer aber checked Exceptions einzusetzen ist nun mal ein ziemlich falscher weg

Nein gerade nicht, du musst eben auf checked Exceptions reagieren und das solltest du nutzen um Fehlverhalten auszuschließen

 

[bygones]

Java ist (afaik) die einzige moderne OOP sprache die auf das konstrukt von checked exceptions setzt... C++ oder c# kennen diese schon gar nicht. Moderne weiterentwicklungen fuer die VM auch nicht (Groovy Scala etc)...

es gibt schon ein Grund warum andere sich davor druecken.

Best Practices for Exception Handling - O'Reilly Media beschreibt es recht nett.

Deine Annahme dass die Nutzung einer RuntimeException Verfremdung sei ist leider einfach falsch.

Des weiteren SOLLTE man Unittests haben die Fehlerfaelle abdecken und das richtige Behandeln sicherstellen... alles ueber checked exceptions sicherstellen zu wollen ist falsch

 

[maki]

Dabei sollte es bleiben, alles andere ist in meinen Augen schlechter Programmierstil.

Mit verlaub, ich erlaube mir zu behaupten dass du einfach noch nicht genug mit (checked) Exceptions gearbeitet hast, was du als "schlechten Programmierstil" siehst ist die "best practice" wenn es um Exceptions geht, findet man in der Literatur & Praxis.

Schon mal korrekten JDBC Code geschrieben?
try/catch Blöcke innerhalb von try/catch Blöcken, aber natürlich ohne die Möglichekit sinnvoll damit umzugehen, denn wenn der Server bzw. das Netzwerk weg ist, gibt es nix was man machen/programmieren kann, was macht man also? Genau, schlucken von Exceptions.....

 

[tfa]

Ich kenne checked Exceptions auch nur in Java.
In Groovy (Java-kompatibel) hat man sie wieder ausgebaut.
In C# (eigentlich ziemlich Feature-geil) hat man sie nicht übernommen.
In Hibernate hat man sie anfangs verwendet, aber vor ca. 5 Jahren ausnahmslos durch RuntimeExceptions ersetzt.
Das Spring-Framework benutzt ebenso keine checked Exceptions.
Hier noch ein Artikel von Bruce Eckel: Bruce Eckel's MindView, Inc: Does Java need Checked Exceptions?

 

[Atze]

es gibt schon ein Grund warum andere sich davor druecken.

ja, weil sie vielleicht nicht richtig damit umzugehen wissen. wie in dem artikel beschrieben, sollte man sie halt direkt im auftretenden layer behandlen oder zumindest nicht unmittelbar/unverarbeitet weiterpropagieren, damit die oberen layer nicht unhandlebare exceptions reingeworfen bekommen. dann ist doch alles gut bin froh, dass es in java die checked gibt, und der compiler einem über die schulter schaut

 

[musiKk]

Warum sollte man nicht auf unchecked Exceptions reagieren? Man kann sie genauso behandeln wie checked Exceptions. Man muss es aber nicht. Das ist der einzige Unterschied.

Ich sage nur, dass das die Intention war oder ich zumindest derartige Interpretationen las (also checked - fangen/weiterwerfen, unchecked - nicht fangen, da Programmierfehler).
Das war nur zur Beantwortung einer der Kernfragen aus dem ersten Post und sollte auch völlig wertungsfrei gewesen sein; die Diskussion hat ja schon einen Bart und macht mir persönlich überhaupt keinen Spaß (mehr).

 

[maki]

ja, weil sie vielleicht nicht richtig damit umzugehen wissen.

Nö, sondern weil checked Exceptions ein Designfehler sind, von Grund auf.

damit die oberen layer nicht unhandlebare exceptions reingeworfen bekommen

Was heisst den "unhandlebare Exceptions"?
RuntimeExceptions können exakt so behandelt werden wie checked Exceptions, nur ohne die ganzen Nachteile.

 

[Atze]

Was heisst den "unhandlebare Exceptions"?
RuntimeExceptions können exakt so behandelt werden wie checked Exceptions, nur ohne die ganzen Nachteile.

um das beispiel aus dem artikel zu nehmen:
wenn exceptions aus der model-ebene (datenbank) sinnlos als bspw. SQLExceptions in die geschäftslogik geschmissen werden.

 

[maki]

um das beispiel aus dem artikel zu nehmen:
wenn exceptions aus der model-ebene (datenbank) sinnlos als bspw. SQLExceptions in die geschäftslogik geschmissen werden.

SQLExceptions sind doch checked Exceptions, also musst du diese sowieso fangen und übersetzen (exception translation), ausser du willst die Geschäftslogik von SQLExceptions abhängig machen. :autsch:
Dasselbe macht man mit RuntimeExceptions.. nur sauberer
Nebenbei, das ist nicht die Model-Ebene, sondern die Persistenz-/Integrationsebene.

 

[Atze]

SQLExceptions sind doch checked Exceptions, also musst du diese sowieso fangen und übersetzen (exception translation), ausser du willst die Geschäftslogik von SQLExceptions abhängig machen. :autsch:
Nebenbei, das ist nicht die Model-Ebene, sondern die Persistenz-/Integrationsebene.

ja, davon red ich doch! ich glaub wir reden in die gleiche richtung, aber an einander vorbei die businesslogik soll da ja nichts (unbrauchbares) von mitbekommen. sie sqlEx sollte man dann ja nicht als checked weiterreichen, weil sie ja dann dort unsinnigerweise behandelt werden müsste. also muss sie ja dann behandelt oder übersetzt werden. und wie wir die ebene nennen, ist ja nur nebensache, oder? sorry, wenns falsch rüberkam! freundschaft!?!

 

[maki]

ja, davon red ich doch! ich glaub wir reden in die gleiche richtung, aber an einander vorbei die businesslogik soll da ja nichts (unbrauchbares) von mitbekommen. sie sqlEx sollte man dann ja nicht als checked weiterreichen, weil sie ja dann dort unsinnigerweise behandelt werden müsste. also muss sie ja dann behandelt oder übersetzt werden. und wie wir die ebene nennen, ist ja nur nebensache, oder? sorry, wenns falsch rüberkam! freundschaft!?!

Freundschaft sowieso...
In einem Schichtenmodell dürfen sowieso bestimmte Exceptions an die nächste "höhere" Schicht weitergegeben werden, da kommt man um ein [c]catch (Exception e) ...[/c] nicht herum.

Ob ich drunter checked oder unchecked Exceptions verwende ist da egal(ausser für den Code und das Design), aber wenn ich zB. in der Persistenz Schicht Hibernate einsetze, will ich ja nicht HibernateExceptions bis in die GUI bekannt machen müssen.

 

[Atze]

mein ich ja

 

[Tomate_Salat]

Mit verlaub, ich erlaube mir zu behaupten dass du einfach noch nicht genug mit (checked) Exceptions gearbeitet hast, was du als "schlechten Programmierstil" siehst ist die "best practice" wenn es um Exceptions geht, findet man in der Literatur & Praxis.

Ich habe genug mit Exceptions gearbeitet ;-)

was macht man also? Genau, schlucken von Exceptions.....

Wenn es nicht immer sein muss, exceptions zu behandeln, sehe ich kein Problem diese zu schlucken. Trotzdem sehe ich nach wie vor nichts verkehrtes daran, dem Entwickler anfälliges mitzuteilen, was letztendlich hilft Fehler zu vermeiden.

 

[bygones]

Ich habe genug mit Exceptions gearbeitet ;-)

aus unserer sicht nicht ;-) v.a. wenn dich solche konstruktor wie erwaehnt try/catch in try/catch bloecken nicht stoeren...

Wenn es nicht immer sein muss, exceptions zu behandeln, sehe ich kein Problem diese zu schlucken.

ich denke es ist beiden klar dass "exceptions schlucken" gefahrenpotential hoch tausend hat... und sonst ist es genau ein punkt der diskussion. Durch checked exception wirst du gezwungen sie zu schlucken, auch wenn du nix damit anfangen kannst.

Trotzdem sehe ich nach wie vor nichts verkehrtes daran, dem Entwickler anfälliges mitzuteilen, was letztendlich hilft Fehler zu vermeiden.

richtig und das geschieht ueber die API bzw deren Dokumentation. Wer sich daran halten will kann dies tun, wer nicht muss mit moeglichen konsequenzen rechnen. Allen anderen aber etwas aufzuzwingen ist einfach unsinn.

bygones - diskussion tret sich dann irgendwann im kreis

 

[maki]

Ich habe genug mit Exceptions gearbeitet

Sorry, aber das glaube ich niemandem der checked Exceptions gut findet

Wenn es nicht immer sein muss, exceptions zu behandeln, sehe ich kein Problem diese zu schlucken.

So, du findest also überflüssige try Blöcke und leere catch Blöcke gut?
Vielleicht haben wir nur andere Definition von "gut" & "schlecht", zumindest würde es erklären warum du die Best Practice beim Umgang mit Exceptions als "schlechter Programmierstil" siehst.

. Trotzdem sehe ich nach wie vor nichts verkehrtes daran, dem Entwickler anfälliges mitzuteilen, was letztendlich hilft Fehler zu vermeiden.

Dafür gibt es doch JavaDoc, man muss doch keine Designfehler (=checked Exceptions) dafür verwenden.

 

[Tomate_Salat]

aus unserer sicht nicht ;-)

^^ ist mir klar

v.a. wenn dich solche konstruktor wie erwaehnt try/catch in try/catch bloecken nicht stoeren...

Wenn sie sinnvoll sind nicht.

ich denke es ist beiden klar dass "exceptions schlucken" gefahrenpotential hoch tausend hat...

steht wohl außer Diskussion

und sonst ist es genau ein punkt der diskussion. Durch checked exception wirst du gezwungen sie zu schlucken, auch wenn du nix damit anfangen kannst.

richtig und das geschieht ueber die API bzw deren Dokumentation. Wer sich daran halten will kann dies tun, wer nicht muss mit moeglichen konsequenzen rechnen.

Setzt eine gepflegte Dokumentation vorraus...und die ist nunmal nicht immer garantiert. Ist diese unsauber oder man hats einfach mal "vergessen" oder sonst was, dann hat man ungewohlt unbehandelte Exceptions! Das kann dir bei checked nicht passieren.

Allen anderen aber etwas aufzuzwingen ist einfach unsinn.

wir dürften uns doch einig sein, dass Exceptions behandelt werden sollten. Warum also das leben schwer machen und sagen: "schau in die api, auf was du achten musst"?! Letztendl. sollteste du jeden fall abdecken, ergo deine try-catch bleiben im Code, ansonsten haste unbehandelte Exceptions!

bygones - diskussion tret sich dann irgendwann im kreis

Nenne es Meinungsaustausch, ich erwarte und glaube nicht, dass hier iEiner seine Meinung ändert.

 

[Tomate_Salat]

Sorry, aber das glaube ich niemandem der checked Exceptions gut findet

Ich kann nicht glauben dass du uncheckt exceptions gut findest ;-). Andere Entwickler andere Meinungen ;-)

So, du findest also überflüssige try Blöcke und leere catch Blöcke gut?

Nein, zumindest den den Stacktrace würde ich mir ausgeben lassen.

Vielleicht haben wir nur andere Definition von "gut" & "schlecht", zumindest würde es erklären warum du die Best Practice beim Umgang mit Exceptions als "schlechter Programmierstil" siehst.

Nennen wirs: unterschiedliche Meinungen ;-). Meiner Meinung nach sollte, wie vorgesehen, nur die jvm RuntimeExceptions schmeisen.

Dafür gibt es doch JavaDoc, man muss doch keine Designfehler (=checked Exceptions) dafür verwenden.

Ich verwende keine Designfehler ;-) ich verwende checked Exceptions

 

[bygones]

Setzt eine gepflegte Dokumentation vorraus...und die ist nunmal nicht immer garantiert. Ist diese unsauber oder man hats einfach mal "vergessen" oder sonst was, dann hat man ungewohlt unbehandelte Exceptions! Das kann dir bei checked nicht passieren.

du redest doch hier auch von gutem Programmierstil den du verlangst. Ergo gehoert eine API auch dokumentiert.

dein Vorschlag klingt nach "Behandle eine simple Krankheit mit einer wesentlich schlimmeren, dann faellts jedenfalls auf".

falsches vorgehen - just as simple

Nein, zumindest den den Stacktrace würde ich mir ausgeben lassen.

autsch.... autsch... autsch....

 

[tfa]

Nenne es Meinungsaustausch, ich erwarte und glaube nicht, dass hier iEiner seine Meinung ändert.

Macht es dich nicht stutzig, dass du ziemlich alleine mit deiner Meinung da stehst? Ich meine nicht nur hier im Thread, sondern auch gegenüber all die genannten Fachartikel und Framework-/Programmiersprachen-Beispielen.

 

[Tomate_Salat]

du redest doch hier auch von gutem Programmierstil den du verlangst. Ergo gehoert eine API auch dokumentiert.

Leider nicht immer garantiert

dein Vorschlag klingt nach "Behandle eine simple Krankheit mit einer wesentlich schlimmeren, dann faellts jedenfalls auf".

dem kann ich gerade absolut nicht folgen, meiner Meinung nach sage ich soviel wie: "Behandle jede Krankheit und gib für evtl. fälle ein nette Impfung die den Ausbruch verhindern kann"

 

[Tomate_Salat]

Macht es dich nicht stutzig, dass du ziemlich alleine mit deiner Meinung da stehst? Ich meine nicht nur hier im Thread, sondern auch gegenüber all die genannten Fachartikel und Framework-/Programmiersprachen-Beispielen.

Nein, ist meiner Meinung nach eh etwas Subjektives.

Programmiersprachen-Beispielen.

da kannst du auch gleich anführen: [c];[/c] sind unnötig, python hat keine und soweit ich gesehen habe (korrigiert mich wenn ich falsch liege) Scala auch nicht.

 

[maki]

Ich kann nicht glauben dass du uncheckt exceptions gut findest . Andere Entwickler andere Meinungen

Kannst dich ja mal umsehen, du vertritst eine Einzelmeinung, die leider falsch ist.

Nein, zumindest den den Stacktrace würde ich mir ausgeben lassen.

Was füßr einen Stacktrace denn??
Wir reden auch von Exceptions die gar nicht auftreten können, wo der try/catch Block nur vom interface (throws <irgendeine checked Exception>) erzwungen wird.
Möchtest du dazu ein Beispiel?

Nennen wirs: unterschiedliche Meinungen . Meiner Meinung nach sollte, wie vorgesehen, nur die jvm RuntimeExceptions schmeisen.

Wie kommst du den auf sowas???
Nochmals:

RuntimeException is the superclass of those exceptions that can be thrown during the normal operation of the Java Virtual Machine.

Da steht nirgendwo dass RTE nur von der JVM geschmissen werden sollen, dürfen oder dass es jemals so gemeint war.
Deine Behauptung dass RTEs so gemeint waren stammt vielleciht daher dass du den Text falsch verstanden hast, aber Fakten gibt es keine dafür.

Ich verwende keine Designfehler

doch hier

ich verwende checked Exceptions

 

[tfa]

Nein, ist meiner Meinung nach eh etwas Subjektives.

Die Meinungen zum GOTO-Statement oder zur Pointerarithmetik ist sicherlich auch was subjektives. Trotzdem gibt es einen weit verbreiteten Konsens.

da kannst du auch gleich anführen: [c];[/c] sind unnötig, python hat keine und soweit ich gesehen habe (korrigiert mich wenn ich falsch liege) Scala auch nicht.

Das hat doch überhaupt nichts mit dem Thema zu tun.