Ich weiß nicht, wie man das in Java-Desktop-Programmen tut, weil ich das noch nie programmiert habe. In Java-Servlets jedenfalls ist es durchaus Usus, alle Ausnahmen, an denen man nicht interessiert ist, nach oben durchzureichen, weil der Applikationsserver dann einen sauberern Traceback fürs Debugging in die Log-Dateien schreibt und man nicht Gefahr läuft, mit einem inkonsistenten Zustand weiterzuarbeiten. Ich persönlich würde das auch bei Desktop-Programmen tun, da der Traceback im Falle einer ungewöhnlichen Ausnahme viel wichtiger ist als eine nichtssagende Fehlermeldung.sparrow hat geschrieben:Auch das ist falsch.ice2k3 hat geschrieben:Mal abgesehen davon kann man die Exception in Java genau so nach oben weiter reichen (mit dem Schlüsselwort throws), das Abfangen der Exception ist nicht Pflicht!
In diesem Fall muss der Aufrufer dann die Fehlerbehandlung übernehmen oder weiterreichen. Ein "Unterschlagen" wie in Python ist somit nicht möglich, spätestens in der Main-Methode wird niemand auf die Idee kommen per throws weiter zu reichen.
Meiner Erfahrung nach führt dieses Feature vor allem dazu, dass Ausnahmen an den unmöglichsten Stellen abgefangen und mit einem "System.out.println("Error occured: " + e.getMessage())" abgehandelt werden. Dabei geht der fürs Debugging essentielle Traceback verloren, und zudem läuft das Programm mitunter in einem völlig inkonsistenten Zustand weiter anstatt sauber zu terminieren.
Außerdem verhindert dieses Feature, dass man Dinge, die Ausnahmen werfen könnten, als Iterator implementiert. Die entsprechende Schnittstelle in Java wirft keine Ausnahmen, daher darf auch eine Implementierung keine Ausnahmen werfen. Einen Iterator zu implementieren, der "for (String line: file)" in Java ermöglicht, ist deswegen völlig unsinnigerweise unmöglich.
Meiner persönlichen Erfahrung nach verringert dieses Feature die Qualität von Java-Programmen meist eher, da die meisten Programmierer einfach eine generische Ausnahmeklausel schreiben, die alles abfängt und alle Debugging-Informationen verschluckt. Außerdem funktioniert es in anderen statischen Sprachen wie C# oder C++ ja auch ohne.