Best Practices Exception Handling für eigene library

[mephi]

Hi,

bezüglich Exception Handling in der eigenen library hätte ich mal ein paar Fragen. Wie handhabt ihr das? Ich benutze innerhalb meiner library eine eigene RuntimeException, einfach der Lesbarkeit halber. So nun sollte nach außen hin aber schon bekannt sein welche Exceptions geworfen werden. Eine Überlegung war nun dass jede Methode die in der API definiert ist ein

throws ..

anzuhängen und zwar mit einer zweiten eigenen Exception als CheckedException. Irgendwie bin ich mir aber unsicher.
Gibts da best practices?

 

[maki]

Best Practice: Keine checked Exceptions

Ansonsten jede Exception die geworfen werden könnte immer Dokumentieren.

 

[SlaterB]

um ein Beispiel zu nennen: Hibernate, Query-Klasse

list

public List list()
throws HibernateException

Return the query results as a List. If the query contains multiple results pre row, the results are returned in an instance of Object[].

Returns:
the result list
Throws:
HibernateException

uniqueResult

public Object uniqueResult()
throws HibernateException

Convenience method to return a single instance that matches the query, or null if the query returns no results.

Returns:
the single result or null
Throws:
NonUniqueResultException - if there is more than one matching result
HibernateException

alles RuntimeExceptions, also wohl wie du es vorschlägst (edit: ok, abgesehen von checked oder nicht),
nicht schön, aber denkbar

 

[mephi]

Dann muss ich entweder an jede public Methode throws anhängen oder ich muss verfolgen von wo eine Exception alles hinfliegen kann(also eine Methode die von ausen aufgerufen wird) und dann diese Methoden entsprechend mit dem throws deklarieren!? Wenn dann noch Objekte herausgegeben werden die wiederum Methoden anbieten die aufgerufen werden können, kann das doch sehr aufwendig sein.

 

[maki]

Hä?

Du musst kein "throws" ranhängen, best practice ist die möglichen Exceptions zu dokumentieren (JavaDoc @throws).
Wenn dir das Dokumentieren zu aufwändig ist, solltest du bedenken das Public APIs immer aufwändig sind.

 

[mephi]

Ok, falsch verstanden.
Aber was ich meine: Bei checked Exceptions seh ich ja schön wo sie hinfliegen. Wenn kein try-catch-Block drum ist und kein throws an der Methode, dann meckert die IDE. So muss ich nun praktisch von Hand verfolgen wo eine Exception ankommen kann oder ich sag eben von vornherein dass jede Methode die von ausen aufgerufen werden kann meine RuntimeExcpetion werfen kann.

 

[SlaterB]

@maki
also zumindest in dem Hibernate-Beispiel steht das doch anscheinend direkt an den Methoden dran,
ob gut oder schlecht mag man streiten, abwegig ist es damit doch zumindest nicht an dieser Stelle

ich denke das gehört zusammen (throws + JavaDoc-Eintrag)

 

[maki]

Sieh es mal so:
Überprüfe deine Unittests welche die Exceptions kontrollieren, dann weisst du ja schon wo was fliegen kann.

Mal ernsthaft: Du (als Author), solltest schon eine Ahnung haben wo welche Exception unter welchen Umständen fliegt, Exceptionhandling gehört zum API Design.

Checked Exceptions an sich haben soviele Nachteile dass man sie nicht mehr verwendet, siehe moderne Frameworks/APIs, sieh andere Sprachen (keine ausser Java kennt checked Exceptiions, und in Java hat man sie oft weggewünscht).

@maki
also zumindest in dem Hibernate-Beispiel steht das doch anscheinend direkt an den Methoden dran,
ob gut oder schlecht mag man streiten, abwegig ist es damit doch zumindest nicht an dieser Stelle

ich denke das gehört zusammen (throws + JavaDoc-Eintrag)

Schon richtig SlaterB, beides sollte vorhanden sein, zumindest aber die Doku.

 

[mephi]

Sieh es mal so:
Überprüfe deine Unittests welche die Exceptions kontrollieren, dann weisst du ja schon wo was fliegen kann.

Mal ernsthaft: Du (als Author), solltest schon eine Ahnung haben wo welche Exception unter welchen Umständen fliegt, Exceptionhandling gehört zum API Design.

Checked Exceptions an sich haben soviele Nachteile dass man sie nicht mehr verwendet, siehe moderne Frameworks/APIs, sieh andere Sprachen (keine ausser Java kennt checked Exceptiions, und in Java hat man sie oft weggewünscht).

Das Problem ist dass ich den Code übernommen habe und die Kernfunktinalitäten eigentlich soweit stehen. Und da ich von Haus aus ein fauler Mensch bin, dachte ich da gibt es eine elegante Lösung 😀
Aber gut, danke für eure Antworten. Nun weiß ich immerhin dass es so richtig ist wie ich es mache und somit wurde immerhin dieses wichtigere Anliegen zufriedenstellend geklärt 🙂