Java und throw?

Hi,

wie wird denn allgemein oder normalerweise ein Java-Code ausgerichtet. Sollte jede Methode eine Exception zurückwerfen?
Das wäre ja mit sehr viel aufwand verbunden für jede Methode eine eigene Exception zu deklarieren?

Oder sollte das nur bei Methoden gemacht werden. die wirklich eine potenzielle Unsicherheit/ bzw. Fehlerquelle aufweisen?.

Vielleicht kann jemand dazu stellung nehmen, der in diesem Bereich ein paar Erfahrungen gesammelt hat.

Ciao

Natürlich soll nicht jede Methode eine Exception werfen, würde bei den meisten gettern auch keinen Sinn machen.

Eigentlich sollte (immer) dann eine Exception geworfen werden, wenn in einer Funktion ein Fehler aufgetreten ist und der Aufrufer darüber informiert werden soll.

Es gibt auch unterschiedliche Exceptions: RuntimeExceptions (NullPointerException...) die müssen nicht gefangen bzw. mit throws angegeben werden und normale Exceptions die gefangen werden müssen.

Gutes Exception handling und logging macht auch das Debuggen viel einfacher.

Griffin

Ich mache zB sowas

public void processHierarchy ( final File file ) {
   if ( file == null ) 
      throw new NullPointerException ( "..." );
   //...
}

public void nextState ( int index ) {
   if ( index <= 0 )
      throw new IllegalArgumentException ( "..." );
      //..
}

MachIchMal schrieb:

Es gibt auch unterschiedliche Exceptions: RuntimeExceptions (NullPointerException...) die müssen nicht gefangen bzw. mit throws angegeben werden und normale Exceptions die gefangen werden müssen.

Genau. Diese beiden Exception-Arten sollte man unterscheiden, denn sie haben auch unterschiedliche Anwendungsgebiete:

RuntimeExceptions nutzt man bei Programmierfehlern. Zum Beispiel dann, wenn jemand eine Methode falsch aufruft (Definitionsbereich wurde nicht beachtet oder irgendwas ist null oder so). Das hat Griffin ja schon gezeigt. Es geht dabei also um Fehler in externem Code, die in der eigenen Methode auffliegen. Bezüglich möglichen internen Fehlern, macht man eigentlich nur Überprüfungen von Zwischenergebnissen und so weiter mit assert. Da schmeißt man keine RuntimeException oder so. Insgesamt ist es glaube ich nicht sehr üblich, RuntimeExceptions zu fangen. Die zeigen eigentlich Bugs und keine "Ausnahmen" an. Alle Auslöser von RuntimeExceptions sollte man während der Entwicklung des Programms beseitigen.

Andere Exceptions sind normalerweise für echte Ausnahmesituationen, die nichts mit dem Programmierer zu tun haben. Also beispielsweise "Ratte zerbeißt das Netzwerkkabel" oder so. Der Programmierer sollte dafür sorgen, dass sein Programm in solchen echten Ausnahmesituationen sinnvoll weiter funktioniert und deshalb sollte man solche Ausnahmen i.d.R. fangen. Im catch-Block sollte man dann dafür sorgen, dass das Programm wieder in einen sinnvollen Zustand überführt wird und, dass der Nutzer möglich wenig Probleme durch die Ausnahme bekommt. Möglicherweise ist es sinnvoll, an dieser Stelle bestimmte Daten zu sichern oder so. Der Nutzer sollte natürlich auch über die Ausnahme informiert werden. Leere catch-Blöcke sind diesbezüglich nicht zu empfehlen. Dann merkt nämlich keiner, dass da etwas pasiert ist. Ein catch(Exception e) sollte man auch vermeiden, da man damit auch RuntimeExceptions fängt. Da macht man dann schnell mal irgendwelche Fehlinterpretationen, was die Exception betrifft.

Ansonsten gibt es noch Errors. Die sollte man nicht fangen. Ein Error heißt "Die JVM befindet sich jetzt in einem undefinierten Zustand". Das heißt, dass man in seinem Programm keine sinnvollen Annahmen mehr machen kann und deshalb sollte das Programm auch sofort beendet werden. Errors sollte man also eher vermeiden. Man könnte zum Beispiel testen, ob noch genug Speicher auf dem Heap frei ist, wenn man an eine Stelle gelangt, die diesbezüglich kritisch ist. Dadurch kann man dann OutOfMemoryErrors im Vorfeld aus dem Weg gehen.

Insgesamt hat man in Java nicht so viele try-catch-Blöcke, wie man vielleicht denken könnte. Die betreffen im Normalfall nämlich nur wenige Codebereiche: IO zum Beispiel oder auch Bereiche mit Reflection. Man sollte also eher sparsam mit Exceptions umgehen und sich immer fragen, ob es sich in einer Situation tatsächlich um eine echte Ausnahme handelt, auf die der Programmierer keinen Einfluss hat.