JavaDoc Runtime-Exceptions: Wie sinnvoll anzeigen?

Werzi2001

Mitglied
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
 
B

Beni

Gast
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

Mitglied
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
 
Zuletzt bearbeitet:
B

Beni

Gast
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.
 
M

maki

Gast
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

Mitglied
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

Top Contributor
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
Java:
/**
 * @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
Java:
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

Mitglied
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

Top Contributor
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

Mitglied
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

Top Contributor
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

Gesperrter Benutzer
Hm... verstehe ehrlich gesagt nicht warum der A
Code:
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
Code:
checkRights()
nicht einfach
Code:
false
oder
Code:
true
zurück. Wo ist da der Fehler/die Ausnahme, wenn keine Rechte vorhanden sind?
Warum gibt
Code:
getById()
nicht einfach
Code:
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.
Code:
getCurrentEntityList()
kann dann einfach per if auf
Code:
false
oder
Code:
null
bei Aufruf der oben genannten Methoden prüfen und entsprechend handeln. Ergo auch wieder
Code:
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

Top Contributor
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

Top Contributor
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

Top Contributor
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
 
Ähnliche Java Themen
  Titel Forum Antworten Datum
I JavaDoc SEO-freundlich gestalten Allgemeine Java-Themen 14
MiMa Was sollte man ins JavaDoc implementieren?? Allgemeine Java-Themen 17
K JDK installieren JavaDoc hinzufügen Allgemeine Java-Themen 10
R Probleme mit Javadoc Allgemeine Java-Themen 2
V Javadoc-Tags Allgemeine Java-Themen 2
S Javadoc hört einfach auf Allgemeine Java-Themen 4
S javadoc java.lang.NullPointerException Allgemeine Java-Themen 2
D Javadoc - API-Dokumentation Allgemeine Java-Themen 2
J Eclipse Javadoc mit Eclipse erstellen Allgemeine Java-Themen 10
P javadoc als pdf Allgemeine Java-Themen 3
B javadoc, 2 sprachig Allgemeine Java-Themen 3
S Javadoc 3d einbinden macht probleme Allgemeine Java-Themen 10
DEvent Wieso ist Javadoc mit Html Tags? Allgemeine Java-Themen 47
X Javadoc Allgemeine Java-Themen 10
hdi Javadoc Comments: IllegalArgumentException deklarieren? Allgemeine Java-Themen 3
J Eclipse JavaDoc Template Allgemeine Java-Themen 16
P JavaDoc und Backslashes: "Invalid unicode" Allgemeine Java-Themen 3
C eine eigene Javadoc erstelen Allgemeine Java-Themen 3
S JavaDoc aus .class Datei extrahieren Allgemeine Java-Themen 5
M Javadoc | Javadoc Eintrag des verlinkten Element einbetten? Allgemeine Java-Themen 4
M Ant & javadoc-Task Allgemeine Java-Themen 1
G JavaDoc: Spezielle Beschreibung nur in Method Detail Allgemeine Java-Themen 5
Schandro Annotation vs Javadoc bei Konstanten Allgemeine Java-Themen 2
G Javadoc Sichtbarkeiten Allgemeine Java-Themen 3
B JavaDoc auf deutsch? Allgemeine Java-Themen 8
G javadoc fehler bei rawtypes Allgemeine Java-Themen 3
S javadoc inheritDoc funktioniert nicht Allgemeine Java-Themen 6
D javadoc interface + implementation + @overrides Allgemeine Java-Themen 16
S Javadoc einbinden Allgemeine Java-Themen 8
T JAR mit embedded Source/JavaDoc? Allgemeine Java-Themen 8
H Frage zu JavaDoc Allgemeine Java-Themen 5
V javadoc mergen / aus mehreren eclipse plugins ein javadoc Allgemeine Java-Themen 3
T JavaDoc Allgemeine Java-Themen 2
G Javadoc generiert keine Links zu java.lang Klassen? Allgemeine Java-Themen 4
G Bilder in javadoc einbinden Allgemeine Java-Themen 5
Y Javadoc - Wie Parameter ansprechen bei Methodenkommentar Allgemeine Java-Themen 2
F Javadoc: @value tag nicht für private fields? Allgemeine Java-Themen 11
G Javadoc Zeilenumbruch Allgemeine Java-Themen 2
N Javadoc in Deutsch? Allgemeine Java-Themen 9
@ Javadoc: Kurzbeschreibung Packages Allgemeine Java-Themen 10
F Linguistische Fragen zu Javadoc bzw. Englisch Allgemeine Java-Themen 4
padde479 javadoc.exe Eclipse Allgemeine Java-Themen 3
G javadoc macht probleme Allgemeine Java-Themen 2
T Konstruktoren werden nicht in Javadoc angezeigt Allgemeine Java-Themen 2
T Über Javadoc hinausgehende Doku? Allgemeine Java-Themen 4
M Wie lädt Eclipse die Javadoc Allgemeine Java-Themen 14
K Javadoc, was gehört rein? Allgemeine Java-Themen 10
Redfrettchen Javadoc unter Eclipse Allgemeine Java-Themen 2
T Javadoc deutsch? Allgemeine Java-Themen 5
G CSS für Javadoc Allgemeine Java-Themen 2
C javadoc Allgemeine Java-Themen 4
P Javadoc -> Autmatisiertes @version Tag Allgemeine Java-Themen 6
S javadoc: package problem Allgemeine Java-Themen 3
A Javadoc erzeugen Allgemeine Java-Themen 4
G javadoc, pakete Allgemeine Java-Themen 3
M JavaDoc per Batch? Allgemeine Java-Themen 7
I Probleme mit Javadoc (5.0 RC) Allgemeine Java-Themen 6
B Wie sehen gute JavaDoc-Kommentare aus? Allgemeine Java-Themen 10
V Javadoc ertellt keine korrekten links Allgemeine Java-Themen 3
chik JavaDoc als PDF oder RTF Allgemeine Java-Themen 3
M Registry Autostart Eintrag ertstellen mit Java (Runtime.getRuntime().exec()) Allgemeine Java-Themen 0
M this application requires a java runtime environment 1.8.0 Allgemeine Java-Themen 2
S Gibt es eine Moeglichkeit die Runtime Ausführung zu analysieren..? Allgemeine Java-Themen 7
J Verschiedene Runtime Versionen gleichzeitig? Allgemeine Java-Themen 12
K Threads Runtime und Process Probleme Allgemeine Java-Themen 3
H Runtime reagiert erst wenn Programm abbricht Allgemeine Java-Themen 1
J Probleme mit der Java-Runtime Allgemeine Java-Themen 10
M Runtime.exec() verursacht auf manchen Systemen Probleme - Ursache unklar Allgemeine Java-Themen 2
S Command funktioniert in Kommandzeile aber nicht mit ProcessBuilder bzw. Runtime.exec auf MAC Allgemeine Java-Themen 3
D Java Objekt als Service in Runtime registrieren Allgemeine Java-Themen 1
Thallius Runtime.getRuntime().exec " escapen? Allgemeine Java-Themen 9
W Threads Mit Thread und Runtime externe Programme öffnen Allgemeine Java-Themen 0
C Runtime Problem Allgemeine Java-Themen 1
P programm öffnen mit der runtime Allgemeine Java-Themen 9
N Runtime.getRuntime().exec Problem mit find Allgemeine Java-Themen 3
P Runtime bzw. RAM-Auslastung eines Prozesses Allgemeine Java-Themen 9
M Befehl in Runtime ausführen der Eingabe benötigt Allgemeine Java-Themen 3
aze Jar ausführen über Runtime.execute funktioniert nicht Allgemeine Java-Themen 4
T Bluescreen bei Runtime.exec(); Allgemeine Java-Themen 8
I Runtime.getRuntime().exec Problem Allgemeine Java-Themen 4
G Runtime.exec beendet Programm unter Linux, wenn Java Programm beendet wird Allgemeine Java-Themen 3
N Runtime.exec() Exception Problem Allgemeine Java-Themen 3
N Runtime.exec() Allgemeine Java-Themen 7
S Runtime Exceptions in eine Datei schreiben Allgemeine Java-Themen 7
N Internet Explorer mit bestimter Java Runtime starten Allgemeine Java-Themen 2
truesoul Runtime.getRuntime().exec nebenbei ausführen Allgemeine Java-Themen 12
S Runtime.getRuntime()... Allgemeine Java-Themen 6
Z Runtime.getRuntime().exec-Problem Allgemeine Java-Themen 4
J Runtime.exec setzt Fokus auf Frame Allgemeine Java-Themen 2
V Probleme mit Runtime.exec() Allgemeine Java-Themen 3
M Runtime.exec() - Performance / Frage zu Threads Allgemeine Java-Themen 5
S Rückgabewert runtime Allgemeine Java-Themen 11
M Runtime.getRuntime().exec(cmd); auf windows ... Allgemeine Java-Themen 2
martin82 Java Runtime Update >17 - SwingWorker Änderungen? Allgemeine Java-Themen 7
T Runtime.exec() Allgemeine Java-Themen 3
X Wann ist Runtime.getRuntime().exec mit Copy fertig? Allgemeine Java-Themen 10
W java ohne runtime Allgemeine Java-Themen 2
G Output eines über Runtime.getRuntime.exec gestarteten Jars Allgemeine Java-Themen 6
N runtime.exec() Problem Allgemeine Java-Themen 6
W Runtime.getRuntime().exec() Allgemeine Java-Themen 10

Ähnliche Java Themen

Neue Themen


Oben