Ich bin immer etwas erstaunt, wie in Java das Thema Fehlerbehandlung gehandhabt wird - dies mal erläutert am Beispiel von ClassLoader.getRessource() (des üblichen). Wenn es eine Ressource nicht gibt, erhält man anstelle einer url null. Wenn man nun nicht in eine NPE rennen will, weil ein Torfkopf eine Datei im Deployment vergessen hat, geht man z. B. wie folgt vor:
Mein Vorgehen mit Exceptions war bislang immer anders. Eine Exception wird dann geworfen, wenn eine Methode/Funktion nicht das ausführen kann, was ich von ihr verlange. Im Beispiel würde also getResource eine Exception werfen. Flankierend dazu habe ich immer eine Methode "has..." geschrieben, in dem Fall hasResource().
Das eröffnet mir zwei Möglichkeiten:
a. wenn die fehlende Ressource die Ausführung des Programms sinnlos macht, rufe ich getResource ohne Prüfung auf und kann mir die zusätzliche Fehlerbehandlung sparen, da sie von getResource erledigt wird. Im Fehlerfall sehe ich sofort, was schief gelaufen ist.
b. wenn eine Ressource optional ist, dann kann ich mit hasResource auf ihre Existenz prüfen, bevor ich sie hole, oder try...catch, wobei ich ersteres "sprechender" finde.
Das habe ich unter PHP sehr konsequent durchgezogen, was sich recht positiv auf die Stabilität und Wartbarkeit der Programme ausgewirkt hat. Unter Java wird mir dieser Ansatz gründlich versalzen.
Die Frage, die mich beschäftigt, ist: was ist die an dieser Stelle hinter Java stehende Philosophie, da es offenkundig nicht die meinige ist? Ich möchte die andere Seite erst verstehen, eh ich mich für etwas entscheide.
Java:
public void test() {
URL pic;
String resname;
resname = "images/guffy.png";
pic = this.getClass().getClassLoader().getResource(resname);
if(pic==null) {
throw new Error("could not load "+resname);
}
}Mein Vorgehen mit Exceptions war bislang immer anders. Eine Exception wird dann geworfen, wenn eine Methode/Funktion nicht das ausführen kann, was ich von ihr verlange. Im Beispiel würde also getResource eine Exception werfen. Flankierend dazu habe ich immer eine Methode "has..." geschrieben, in dem Fall hasResource().
Das eröffnet mir zwei Möglichkeiten:
a. wenn die fehlende Ressource die Ausführung des Programms sinnlos macht, rufe ich getResource ohne Prüfung auf und kann mir die zusätzliche Fehlerbehandlung sparen, da sie von getResource erledigt wird. Im Fehlerfall sehe ich sofort, was schief gelaufen ist.
b. wenn eine Ressource optional ist, dann kann ich mit hasResource auf ihre Existenz prüfen, bevor ich sie hole, oder try...catch, wobei ich ersteres "sprechender" finde.
Java:
public void test() {
URL pic;
URL optional;
String resname;
//wenn dieses bild nicht da ist, kann das programm nicht weiter ausgeführt werden
pic = this.getClass().getClassLoader().getResource("images/mandatory.png");
//dieses Bild ist optional.
if(this.getClass().getClassLoader().hasResource("images/optional.png") {
this.getClass().getClassLoader().getResource("images/optional.png");
}
}Das habe ich unter PHP sehr konsequent durchgezogen, was sich recht positiv auf die Stabilität und Wartbarkeit der Programme ausgewirkt hat. Unter Java wird mir dieser Ansatz gründlich versalzen.
Die Frage, die mich beschäftigt, ist: was ist die an dieser Stelle hinter Java stehende Philosophie, da es offenkundig nicht die meinige ist? Ich möchte die andere Seite erst verstehen, eh ich mich für etwas entscheide.
