JavaDoc Runtime-Exceptions: Wie sinnvoll anzeigen?

[Werzi2001]

Hallo zusammen,

ich entwickle aktuell an einem größeren Java-Projekt (Framework), das verstärkt auf Runtime-Exceptions setzt. Obwohl man diese nicht deklarieren muss, würde ich sie gerne (zu Informationszwecken) in die JavaDocs aufnehmen. Nun stellt sich mir aber die Frage wie man das üblicherweise am Besten macht.

Die Basis des Frameworks besteht aus zahlreichen kleinen Methoden, die alle 0-2 Runtime-Exceptions schmeißen können. Darauf aufbauend gibt es umfangreichere Methoden usw. Dadurch können die größere Methoden eine ganze Reihe von Exceptions schmeißen, die zwar nicht von ihnen selbst aber von den aufgerufenen kleinen Methoden kommen. Zur Information wäre es aber wohl trotzdem sinnvoll diese in der JavaDoc anzugeben.

Das Problem ist nun, dass es manuell quasi unmöglich ist alle Exceptions zu ermitteln, die geschmissen werden könnten und diese in die JavaDoc einzutragen (und diese aktuell zu halten). Daher nun meine Fragen: Gibt es für diese Aufgabe Tools? Wie geht man normalerweise mit der steigenden Anzahl an möglichen Exceptions in höheren Abstraktionsebenen um (einfach weglassen?)?

Danke für eure Hilfe

Grüße
Thomas

 

[Beni]

Schreib deinen Code so, dass eine Methode nie eine andere Methode falsch aufruft, dann muss du nur jeweils die obersten Exceptions behandeln (die anderen tretten per Definition nicht auf, oder sie sind ein Bug und Bugs sind logischweise in der Doku nicht beschrieben). Das gibt etwas mehr Schreibarbeit, da du einige Dinge doppelt prüfen wirst, aber je grösser das Projekt desto glücklicher wirst du über Fehlermeldungen "nahe" beim Übeltäter sein. Macht die Fehlersuche viel einfacher,

Also wenn z.B. eine Methode ein paar Parameter hat, muss sie all diese Parameter überprüfen, bevor sie sie weitergeben darf. Wenn ein Parameter falsch ist, dann gibt es natürlich eine Exception.

 

[Werzi2001]

Um ehrlich zu sein bin ich von dieser Lösung nicht ganz überzeugt. Das würde doch nur dazu führen, dass ich Validierungen (die potenziell sehr komplex sein können) redundant ausführe. Es geht ja nicht nur darum etwas doppelt auszuführen. Wenn es über 3, 4 oder mehr Ebenen geht führe ich den Code 3-fach, 4-fach oder noch öfter aus. Teilweise wären für die Validierung auch externe Services (Datenbank, WebService usw.) nötig deren mehrfache Abfrage erheblichen Nachteil für die Performance bringen würde.

Abgesehen von einfachen Validierungen im Stil von "Zahl muss größer 0 sein" sehe ich also keine Möglichkeit das umzusetzen.

Grüße
Thomas

 

[Beni]

Also wenn du externe Services brauchst, dann wären IMHO checked Exceptions eher angebracht. Dann ist es nämlich "normal Verhalten" dass eine Exception auftretten kann.

Aber ich schweige jetzt besser, denn ich kann dir kein Tool anbieten das die Exceptions raussucht.

 

[maki]

Von checked Exceptions würde ich abraten, werden seit jahren (aus guten Gründen) nicht mehr in neueren Frameworks eingesetzt.

Die Basis des Frameworks besteht aus zahlreichen kleinen Methoden, die alle 0-2 Runtime-Exceptions schmeißen können. Darauf aufbauend gibt es umfangreichere Methoden usw. Dadurch können die größere Methoden eine ganze Reihe von Exceptions schmeißen, die zwar nicht von ihnen selbst aber von den aufgerufenen kleinen Methoden kommen. Zur Information wäre es aber wohl trotzdem sinnvoll diese in der JavaDoc anzugeben.

Das Problem ist nun, dass es manuell quasi unmöglich ist alle Exceptions zu ermitteln, die geschmissen werden könnten und diese in die JavaDoc einzutragen (und diese aktuell zu halten). Daher nun meine Fragen: Gibt es für diese Aufgabe Tools? Wie geht man normalerweise mit der steigenden Anzahl an möglichen Exceptions in höheren Abstraktionsebenen um (einfach weglassen?)?

Hmm... höre ich zum ersten mal, dass es "unmöglich" wäre, alle möglichen Exception zu ermitteln.
Dein Design klingt ehrlich gesagt komisch (oberer Abstatz), würde das überdenken, schon mal was von Exception Translation gehört?

 

[Werzi2001]

Ja checked Exceptions scheinen wirklich in modernen Frameworks keine Verwendung mehr zu finden. Zum Beispiel haben weder Hibernate noch Spring checked Exceptions. Rein interessehalber... warum eigentlich?

Hm... verstehe ehrlich gesagt nicht warum der Ansatz komisch sein soll. Mal ein einfaches Beispiel (entspricht nicht der Realität, nur zur Veranschaulichung):
Es gibt eine Methode (checkRights), die die Rechte eines Benutzers prüft und falls er keine hat eine InsufficientRightsException schmeißt.
Außerdem gibt es eine Methode (getById) die einen Datensatz ausliest und falls er nicht gefunden wird eine NotFoundException schmeißt.
Beide zusammen werden in readEntity verwendet, die somit InsufficientRightsException und NotFoundException schmeißen könnte.
Diese wiederum wird zum Beispiel in getCurrentEntityList verwendet. Diese kann somit wieder beide Exceptions schmeißen und eventuell noch weitere von anderen Logiken.

So schaukelt sich das im Prinzip beliebig hoch und es werden immer mehr Exceptions. Exception Translation sagt mir natürlich etwas aber ich sehe eigentlich keinen Sinn darin eine Exception wie InsufficientRightsException extra noch einmal zu verpacken. Das würde nur entsprechende catch-Blöcke komplizierter machen (oder soll man das wirklich so machen?).

Unmöglich ist es natürlich nicht alle möglichen Exceptions zu ermitteln und manuell in die JavaDocs einzutragen aber das ist ohne Tools ein riesiger Aufwand (hunderte Methoden).

Grüße
Thomas

 

[Marco13]

Eine wirklich gute und geschickte "Best Practice"-Lösung würde mich da auch mal interessieren. Bis zu einem gewissen Grad ist das noch handhabbar, aber eine allgemeine Lösung wüßte ich auch nicht - trotz der üblichen "Pauschalplätze" a al "Exceptions dort fangen, wo sie behandelt werden können" etc.

Die einzige Lösung, die mir einfallen würde, wäre das, was vielleicht mit "Exception Translation" gemeint war, auch wenn es der TO anders interpretiert zu haben scheint als ich: Es ist nicht unüblich, Exceptions zusammenzufassen. An dem Beispiel:

Es gibt eine Methode (checkRights), die die Rechte eines Benutzers prüft und falls er keine hat eine InsufficientRightsException schmeißt.
Außerdem gibt es eine Methode (getById) die einen Datensatz ausliest und falls er nicht gefunden wird eine NotFoundException schmeißt.

... ja, und vielleicht noch irgendeine XMLParsingException oder SQLException, je nachdem, welche Datenquelle dahinter steht. Aber die sollte man natürlich NICHT alle auflisten

/**
 * @throws A lot of crap when anything goes wrong anywhere
 */
Data getData() throws InsufficientRightsException, NotFoundException, XMLParsingException, SQLException {
    ...
}

Stattdessen könnte man sie entweder zu allgemeinen Exceptions zusammenfassen

Data getData() throws LoadingException {
    try
    {
        return getDataInternal();
    }
    catch (InsufficientRightsException e) 
    {
        throw new LoadingException(e);
    }
    catch (NotFoundException e)
    {
        throw new LoadingException(e);
    }
    ...

}

private Data getDataInternal() throws InsufficientRightsException, NotFoundException, XMLParsingException, SQLException {
    ...
}

oder, auch unter Berücksichtigung des oben genannten Entscheidungskriteriums nach der Frage, wo man wie auf die Exceptions reagieren kann, etwas gegen die Ursache unternehmen, wenn man kann.

 

[Werzi2001]

Danke für deine ausführliche Antwort. Doch genau das habe ich mit "Exceptions verpacken" gemeint. Also das zusammenfassen zu einer generellen Exception.

Das erleichtert zwar die Deklaration der Exceptions aber verkompliziert man damit nicht das Exception-Handling generell? Im catch der Loading-Exception müsste ich doch dann mit getCause erstmal prüfen was genau schief gegangen ist um dann eventuell darauf zu reagieren (oder auch nicht, je nach Ursache). Das ganze wohl auch wieder in einer Loop weil die Exception eventuell mehrfach "verpackt" wurde.

Grüße
Thomas

 

[Marco13]

Hmja, wie gesagt, das ist kein "Silver Bullet", und ob es sowas gibt, weiß ich nicht.

Dass man ggf. den Cause analysieren muss, stimmt. Bis zu einem gewissen Grad wird das abgemildert, wenn man die Exception so früh wie sinnvoll oder möglich behandelt. Aber ganz vermeiden kann man es wohl nur schwer. Dieses Konzept wurde z.B. ja auch in ExecutionException (Java 2 Platform SE 5.0) antizipiert - ob nun freiwillig oder gezwungernermaßen kann ich gerade nicht einschätzen...

 

[Werzi2001]

Ja leider gibt es dafür wohl keine "Best Practice" Lösung. Da ich normalerweise etwas ganz oder gar nicht mache und es nicht mit vertretbarem Aufwand möglich ist die möglichen Exceptions pro Methode zu definieren (sind ca. 3000 Methoden... hab die Zahl etwas unterschätzt) werde ich es wohl ganz weg lassen.

Grüße
Thomas

 

[FArt]

Ein gutes Design berücksichtig das "law of demeter". Das sollte bedeuten, dass ich lediglich die Exceptions dokumentieren muss, die ich selber werfe. Nur der Aufrufer kann so eine Exception auch sinnvoll behandeln. Alle nicht behandelte Exceptions sind somit Fehler, die nicht behandelt werden können und sollen... und schlagen entsprechend weit oben mit entsprechender Auswirkung auf.

Außerdem: Exceptions sind Ausnahmen. Wenn ich zu viele davon habe, sollte ich mir Gedanken machen...

 

[TheDarkRose]

Hm... verstehe ehrlich gesagt nicht warum der A

nsatz komisch sein soll. Mal ein einfaches Beispiel (entspricht nicht der Realität, nur zur Veranschaulichung):
Es gibt eine Methode (checkRights), die die Rechte eines Benutzers prüft und falls er keine hat eine InsufficientRightsException schmeißt.
Außerdem gibt es eine Methode (getById) die einen Datensatz ausliest und falls er nicht gefunden wird eine NotFoundException schmeißt.
Beide zusammen werden in readEntity verwendet, die somit InsufficientRightsException und NotFoundException schmeißen könnte.
Diese wiederum wird zum Beispiel in getCurrentEntityList verwendet. Diese kann somit wieder beide Exceptions schmeißen und eventuell noch weitere von anderen Logiken.

Sagt mal, bin ich der einzige der findet das dies ziemlich mieser Stil und Missbrauch von Exceptions ist, oder geht es anderen auch so?

Warum gibt

checkRights()

nicht einfach

false

oder

true

zurück. Wo ist da der Fehler/die Ausnahme, wenn keine Rechte vorhanden sind?
Warum gibt

getById()

nicht einfach

null

zurück, wenn kein Datensatz gefunden wird? Wo ist da die Ausnahme wenn kein Datensatz vorhanden ist? Das ist normales bzw. zu erwartendes Verhalten und sollte somit auch normal zurückgegeben werden.

getCurrentEntityList()

kann dann einfach per if auf

false

oder

null

bei Aufruf der oben genannten Methoden prüfen und entsprechend handeln. Ergo auch wieder

null

zurückgeben.

Exceptions sollte man nur - wie es der Name schon sagt - in Ausnahmefällen verwenden, wie z.B. beim Programmieren mit Hibernate, dieses eine RuntimeException schmeißt, sollte die Tabelle aus der Abfrage nicht in der DB existieren (unerwartetes Verhalten, auf das man beim Programmieren keinen Einfluss hat).

 

[mvitz]

Stimme dir prinzipiell zu, aber ( ;-) ) wenn man eine DB Methode hat, die findById heißt, dann erwartet man auch, dass es zu dieser ID einen Datensatz gibt, dementsprechend wäre dann eine Exception besser als null.

Ansonsten stimme ich soweit mit FArt überein.

 

[Empire Phoenix]

Nicht umbedingt, wenn dein domain model das so vorhsieht dass es die id immer geben muss aber runtimeexception. Da du dann auch nichtsmehr retten kannst, da deine domain daten fehlerhaft sind.

Generell sehe ich das so:
Erstmal sollte jede exception so ausführlich wie sinnvoll sein, dh. egal wo sie gefangen wird, es sollte relativ deutlich sein wo das eigentlich problem ist. Zum getid beispiel also ne(annahme es geht um user bei der methode)
new RuntimeException("User with id " + id + " not found, contract breach -> $verweis auf design document wo spezifiziert is das es immer was bei der id geben muss$");

Checked exceptions nur wenn die domain logic vorsieht ds es fehler geben darf. Hier ist dann der streitpunkt, was dar der logic nach auftreten?
Beispielsweise bei einem url request ein 404, dann bei fremdressourcen macht es sinn das ganze checked zu haben um fehlermeldungen anzuzeigen ect.
Was aber wenn sich dahinter ein firmeninternes document befindet, dass laut contract da sein muss? Abfangen ist nur noch begrenzt möglich in dem fall.

Kurz:
mach es so wie es logisch erscheint, jedoch zumindest einheitlich, und documentiere nach welchem prinzip du vorgegangen bist. Das hilft wahrscheinlich mehr als die hinweise in der javadoc.

Ansonsten stimme ich dem mit den null returnen vollkomen zu. Es geht letztendlich das database layer nicht an ob in der applicationslogic die id laut contract existieren muss. Das ist aufgabe der stelle die selbige logic verarbeitet.

 

[FArt]

Null ist durchaus ein sinnvoller Rückgabewert, wenn der Anwendungsfall das so festlegt und dies eben kein Fehlerfall ist (wenn also z.B. ein Schlüssel in einer Map ist... oder auch nicht). Sonst ist es aber (wie schon von so ziemlich allen erwähnt) eine Ausnahme und somit eine Exception.

Nur als Anmerkung:
Im Fehlerfall sollte man nie null zurückgeben. Erst recht nicht, wenn der Fehler bereits durch eine Exception gemeldet wurde, siehe z.B. Exception-Handling Antipatterns | Java.net