Eine Exception für eine fehlende Implementierung

Hallo,

ich suche nach einer guten Umsetzung einer Exception die geworfen wird, wenn ein Detail einer Methode noch nicht implementiert wurde. Ich habe schon gegooglet, aber die java.lang.UnsupportedOperationException ist nicht hilfreich, da sie sich eher auf eine ganze Methode bezieht, oder sehe ich das falsch?

Um das Problem etwas genauer zu beschreiben:
Ich habe eine Extension geschrieben für TestFrameworks (zumindest für JUnit geeignet), in der die Methode ‘void assertEquality(String failureMessage, Object expected, Object actual, Comparison comparisonToUse)’ die zentrale Rolle spielt. Weil nun aber die zwei zu vergleichenden Instanzen eben Objekte sind, gibt es auch kompliziertere Fälle, die ich später implementieren will. Das ist zum Beispiel der Vergleich von primitiven Arrays irgendwelchen Typs. Wenn dieser Fall eintritt, will ich vorläufig so eine Exception werfen.

Ich hatte zunächst an eine NotYetImplementedException gedacht, mit dem Package ‘de.ich.textextension.NotYetImplementedException’. Auf exakt diese Exception reagiert das TestFramework mit einer Ausschrift auf der Konsole. Um aber eine generelle Version zu haben, dachte ich das Package auf null zu setzen und nur den Klassennamen beizubehalten. Und dann zum Beispiel von dieser Exception abzuleiten mit eben einem Package passend zu meiner TestExtension. Damit sind die Möglichkeiten geschaffen universell auf solch eine Exception zu reagieren und andere Entwickler können in eigenen Projekten eine Exception mit neutralem Package erstellen, die dann bei der Verwendung der TestExtension auch berücksichtigt werden.

Meine zentralen Fragen sind nun:

  • Ist der Name NotYetImplementedException eine gute und passende Wahl, oder gibt es Alternativen?
  • ist ein Package mit null zu empfehlen?

Falk

Es ist (für mich) etwas schwierig zu verstehen, dass was mit dem null-Package und dem Vererben bedeuten soll. Vielleicht würde ein Beispiel helfen?

Im allgemeineren Sinne, d.h. bezogen auf die Frage, ob das “ein guter Name” ist - das ist teilweise subjektiv. Ich bin üblicherweise recht zurückhaltend mit dem Einführen eigener Exceptions. Meistens tut’s IllegalArgument. Wenn hier nun etwas “fachliches”, spezifischeres beschrieben werden soll, müßte man (ich) genauer verstehen: Was? Also, was soll da modelliert werden (und wie soll mit der Exception, in bezug auf den ersten Punkt, umgegangen werden) ?)

Noch allgemeiner: Sowas hier…

void assertEquality(String failureMessage, Object expected, Object actual, Comparison comparisonToUse) 

sieht aus, als würde die eigentliche Arbeit an die Comparison delegiert werden. Von wo wird denn die Exception geworfen? Also, stammt diese Exception nicht konzeptuell daher, dass die Comparison mit den übergebenen Objekten nichts anfangen konnte?

Das sieht mir alles zu sehr nach “Jedem Tierchen sein pläsierchen” aus. Eine Operation ist genau auch dann unsupported, wenn in der Implementierung (noch) etwas fehlt. Man kann an die UnsupportedOperationException ja auch einen String anhängen: “{this or that} is not implemented yet”. Eine IllegalArgumentException halte ich persönlich aber eher für eine schlechte Idee, weil das Argument ja nicht wirklich illegal, sondern schlicht die Behandlung dafür noch nicht vorhanden ist.

Eine NotYetImplementedException würde mMn nur dann Sinn machen, wenn man möchte, dass der Aufruf der entsprechenden Methode unbedingt in Try-Catch eingebettet werden soll, um darauf reagieren zu können - die Exception sollte dann nicht RuntimeException erweitern, wie es UnsupportedOperationException tut.

2 „Gefällt mir“

Es ist (für mich) etwas schwierig zu verstehen, dass was mit dem null-Package und dem Vererben bedeuten soll. Vielleicht würde ein Beispiel helfen?

Die NotYetImplementedException wird in der TestExtension dafür benutzt um anzuzeigen, dass Vergleiche von primitiven Arrays irgendeinen Typs nicht unterstützt werden. Jetzt war meine Idee, eine Exception mit ‚neutralem‘ Package anzubieten, damit andere Programmierer in ihren Projekten eine gleichnamige Exception eben mit diesem neutralen Package ebenfalls definieren und speziell für das Projekt eine org.projekt.NotYetImplementedException hinzufügen welche von der oben genannten neutralen Exception ableiten. Damit ist sichergestellt, dass bei der Verwendung der TestExtension diese auch auf die spezielle org.projekt.NotYetImplementedException reagiert.

Das macht natürlich nur dann Sinn, wenn ein Bedarf an solch einer Exception bei anderen Projekten besteht beziehungsweise sie auch genutzt werden. Aufgrund der Tatsache, dass es eine solche Exception noch nicht gibt (mit Ausnahme von ApacheCommons) wird die Akzeptanz eher gering ausfallen. Dennoch möchte ich einfach eine gut gewählte Exception anbieten, welche zur Wiederverwendung geeignet ist.

sieht aus, als würde die eigentliche Arbeit an die Comparison delegiert werden.

Comparison ist eine Enumeration welche die Art und Weise angiebt, wie der Vergleich durchgeführt werden soll. So gibt es bis jetzt: EQUALS und SERIALIZATION. Zukünftig soll noch EQUALS_AND_SERIALIZATION und AUTOMATIC_SELECTION implementiert werden.

Das sieht mir alles zu sehr nach „Jedem Tierchen sein pläsierchen“ aus.

Genau das wollte ich vermeiden, indem ich nach einer bereits existierenden Exception gesucht habe.

Die Idee mit dem angehängten String der UnsupportedOperationException ist eine gute Idee. Wobei ich die Tatsache, dass diese Exception keine RuntimeException ist, dann für mich als ungeeignet ansehe da dies explizit an der Methodensignatur dran steht und bei einer Änderung aller bisher mit der TestExtension gemachten Tests angepasst werden müssten.

Vielleicht gibt es ja noch mehr Punkte für und wieder einer RuntimeException?

Bei solchen Dingen, die global in mehreren Projekten verwendet werden sollen, verwendet ich ein extra Projekt, das dann von allen Projekten, die auf diese Funktionalität zugreifen sollen, verwendet werden.

Warum jemand von der NotYetImplementedException erben sollte, ist mir allerdings nicht klar. Man will doch keine Funktionalität hinzufügen.

Zum Thema checked / nonchecked Exceptions: Ich halte checked exceptions für einen Fehler und kapsel alles sofort in eigene nonchecked Exceptions. Man handelt sich Abhängigkeiten ein und ist sehr unflexibel mit checked exceptions. Dazu finden sich aber auch sehr schlaue und lange Ausführungen.

Warum jemand von der NotYetImplementedException erben sollte, ist mir allerdings nicht klar. Man will doch keine Funktionalität hinzufügen.

Damit wäre sichergestellt, das die TestExtension auch auf eine solche a.b.c.NotYetImplementedException reagieren kann. Funktionalitäten werden sicherlich nicht hinzugefügt.