Verwendung von unchecked exceptions & bereits vorhandenen exceptions was priorisieren

[maulwurfen]

Hallo zusammen,

man liest ja immer wieder, dass man unchecked exceptions den checked exceptions vorziehen soll. Weiterhin gilt es ja als guter Stil, wenn man nicht für alles eine eigene Exception entwerfen soll, sondern auf bereits vorhandene Exceptions zurückgreifen soll (sofern möglich natürlich). Leider beißen sich diese beiden Ansätze von Zeit zu Zeit. Deshalb wäre meine Frage, ob es best practices gibt die einen der beiden Ansätze priorisieren?

Ich habe z.b. eine Methode getFilepath(), die nur einen Dateipfad zurückgeben soll, wenn die Datei bereits gespeichert wurde. Ist dies nicht der Fall, möchte ich einen Exception werfen lassen. Um das zu erreichen, werfe ich einen NoSuchFieldError (unchecked). Jetzt kommt jedoch eine weitere Methode (checkAttachmentState()) hinzu, die den direkten Aufruf der Methode getFilepath() kapselt und in deren Kontext eine FileNotFoundException (checked) viel logischer erscheint als ein NoSuchFieldError.

Meine Frage ist jetzt, was gilt denn in einem solchen Fall als guter Programmierstil? NoSuchFieldError weiterverwenden und somit beide o.g. Ansätze vereinen, auch wenn der Name des Fehlers nicht intuitiv und für den Kontext passend ist? Oder eine checked Exception a la FileNotFoundException werfen, dabei gegen einen der o. g. Ansätze verstoßen und dafür aber eine zum Kontext passende Exception nutzen? Oder doch eine eigene unchecked Exception ableiten? Würde gerne mal eure Meinungen dazu lesen.

Gruß
maulwurfen

 

[maki]

IllegalArgumentException wäre eine Möglichekit, oder eben die FileNotFoundException.
Man kann ja zum Glück (oder war es Absicht?) eine aussagekräftige Message mitliefern..

Ich habe z.b. eine Methode getFilepath(), die nur einen Dateipfad zurückgeben soll, wenn die Datei bereits gespeichert wurde. Ist dies nicht der Fall, möchte ich einen Exception werfen lassen.

Das ergibt nur Sinn, wenn der Client die Möglichkeit hat, vorher zu prüfen ob die Datei auch existiert, sonst wäre der Client ja gezwungen, immer einen try/catch Block zu machen... fast wie bei checked Exceptions

 

[tfa]

Zur Not würde ich eine eigene Runtime-Exception programmieren, statt auf eine checked Exception zurückgreifen zu müssen.
Wenn man eine existierende Exception verwendet, sollte sie schon irgendwie (semantisch) zu der Situation passen, nicht nur dem Namen nach. Diesen NoSuchFieldError würde ich hier nicht verwenden. Ein Error ist doch etwas zu speziell dafür.

 

[maulwurfen]

IllegalArgumentException wäre eine Möglichekit, oder eben die FileNotFoundException.
Man kann ja zum Glück (oder war es Absicht?) eine aussagekräftige Message mitliefern..


Das ergibt nur Sinn, wenn der Client die Möglichkeit hat, vorher zu prüfen ob die Datei auch existiert, sonst wäre der Client ja gezwungen, immer einen try/catch Block zu machen... fast wie bei checked Exceptions

Hallo maki,

danke für deine schnelle Antwort. Grundsätzlich gebe ich dir bei o. g. recht, allerdings kann der Entwickler den Status des Attachments mittels getState() vorher abrufen. Es ist also beabsichtigt, dass eine Exception geworfen werden soll wenn der Entwickler ohne Statuscheck blind auf den Dateipfad zugreifen möchte. Deshalb würde ich aber gerne checkedExceptions vermeiden, da ein catch nicht notwendig ist, wenn man den Status vorher abruft. Und einfach nur null zurückliefern finde ich auch nicht schön, da dies nochmals eine zweite If-Abfrage (neben dem Statuscheck) mit sich bringt um NullPointer zu vermeiden und zudem nach Robert Martin (Clean Code: A Handbook of Agile Software Craftmanship) generell null als Rückgabewert vermieden werden soll.

IllegalArgumentException habe ich bis dato eigentlich immer nur bei Parametern verwendet und habe sie auch diesem Kontext zugeordnet. Sollte ich aber keine geeignetere Exception hierfür finden ist das sicherlich eine Variante, die gangbar wäre. Danke

Hat jemand eigentlich eine gute Übersicht aller unchecked exceptions? Ich kenne nur eine Übersicht aller Ausnahmen (checked und unchecked) unter Java Exceptions List Hai’s Blog und die Listen über unchecked exceptions, die ich gefunden habe, sind doch recht unvollständig.

Gruß
maulwurfen