Rückgabe nicht sinnvoll: Exception oder null zurück?

[Redfrettchen]

Hi,
was ist schöner/eleganter, wenn eine Rückgabe nicht sinnvoll ist:
1. throw Exception oder
2. null zurückgeben?

Also konkret möchte ich den Schnittpunkt einer Strecke mit einer anderen Strecke berechnen lassen. Sollten die Strecken parallel oder identisch sein, löse ich schon mal ne Exception aus, da der Benutzer vorher mit isParallel() oder equals() diese Fälle hätte prüfen können. Sollten die Geraden, dessen Teilmenge die Strecken sind, sich allerdings schneiden, kann es ja immer noch sein, dass eine oder beide Strecken um den Schnittpunkt herum nicht definiert ist, d.h. der Schnittpunkt nicht zwischen den definierenden Punkten liegt. Sollte ich hier auch eine Exception auslösen, oder einfach null als Schnittpunkt zurückgeben?

Bei Exceptions wird ja immer aufwendig der Stack gezogen, also spricht die Performance für null. null ist allerdings eine im Grunde nichtssagende Antwort auf den Methodenaufruf. In diesem Fall könnte man ja noch argumentieren, dass null nur zurückgegeben wird, wenn sich zwar die Geraden, aber nicht die Strecken schneiden.

 

[LazyL]

Also null zurückgeben ist immer problematisch, da es schnell zu NullpointerExceptions an anderer Stelle kommen kann, und dann die Fehler Suche manchmal etwas dauern kann. Also würde ich dazu raten eine Exception zu werfen.
Eine weitere Möglichkeit ist das Vertragsmodell mit Vor- und Nachbedingungen durch assertions zu realisieren, was vielleicht auch bei Parallelität und Gleichheit eleganter wäre.

 

[byte]

Naja, Assertions müssen ja beim Ausführen explizit aktiviert werden (oder wurde das mit Java 5 geändert?). Desweiteren nutzt Du sie zum Auffinden und Korrigieren von Bugs. In diesem Fall scheint es ja wenn ich richtig verstanden habe kein Bug zu sein, wenn die Berechnung mit zwei parallelen Strecken aufgerufen wird. Null zurückgeben funktioniert natürlich solange, wie Du bei jedem Aufruf der Methode den Fall "null als Rückgabe" weiter behandelst. Vergisst Du das mal, kriegst Du ne NullPointerException. Demnach ist es imo sauberer, wenn Du ne Exception wirfst in Deiner Berechnung, z.B. ne IllegalArgumentException oder Du definierst Dir eine eigene. Dann wirst Du gezwungen, diese Exception auch zu catchen und vermeidest Fehler, die sonst z.B. bei Wiederverwendung der Methode zu einem späteren Zeitpunkt durch Dich oder irgendjemand anderen auftreten könnten.

 

[Bleiglanz]

in dem Fall wäre ich für null

(müsste halt in der javadoc genau spezifiziert werden)

if(null!=schnittpunkt){

}

find ich halt irgendwie schöner als die Exception - und es ist ja auch keine "Ausnahme" wenn sich zwei Geraden mal nicht schneiden...

 

[norman]

normalerweise könnte man es doch auch etwa so machen::

Point schnittpunkt;
if (schnittpunktExists(gerade1, gerade2) {
   schnittpunkt = getSchnittpunkt(gerade1, gerade2)
}

für den Fall, dass hier kein Schnittpunkt exisitert, bleibt schnittpunkt ja auch null... ???:L
=> ich finde null also durchaus logisch an dieser stelle

 

[bygones]

ich würde noch ne boolean methode intersects oder so einbauen, die überprüft, ob sich 2 geraden schneiden....

 

[norman]

ich würde noch ne boolean methode intersects oder so einbauen, die überprüft, ob sich 2 geraden schneiden....

das ist ja genau was ich eben gepostet hatte :wink:

 

[bygones]

ich würde noch ne boolean methode intersects oder so einbauen, die überprüft, ob sich 2 geraden schneiden....

das ist ja genau was ich eben gepostet hatte :wink:

stimmt gut gemacht

 

[Redfrettchen]

Jo, hab ich auch, aber wenn man beides aufruft hat man halt doppelte Arbeit. Da fänd ich aber Exception/null besser.

 

[Dante]

eine exception ist eine Ausnahme, also irgendein Fehler in der Applikation der noch die Chance hätte bearbeitet zu werden, imho ist der hier genannte Fall aber kein fehler sondern einfach nur ein möglicher Rückgabewert eines Algorithmus, daher sollte null zurückgegeben werden, um anzuzeigen das es keinen Schnittpunkt gibt