Exceptions in methoden auslöesen = sauber?

[me3]

Hi,

wollte mal fragen ob es "sauberes" programmieren ist wenn ich in methoden eigene exceptions auswerfe oder sollte man sowas umgehen?

z.B. wenn eine methode einen String / Integer zurückliefert, beid er berabeitung aber eine bedingung eintrigtt und der string nicht berabeitet werden konnte, sollte man dann null zurückliefern oder eine exception auslösen?

 

[stev.glasow]

Beschreib mal genauer was da passiert, aber eigentlich wäre ich für eine Exception, wenn z.B. das Eintreten dieser Bedingung von einem Übergabeparameter abhängt würde ich eine IllegalArgumentException werfen.

 

[SnooP]

Du musst dir für dich definieren was die Methode für Eingabeparameter benötigt bzw. welche Schritte für die Methode "normal" sind... dann solltest du dir Ausnahmen überlegen. Wenn eine Ausnahmesituation eintritt, sollte auch eine Exception geworfen werden, weil das Programm ja dadurch unter Umständen fehlerhaft werden könnte - wenn man nur null liefert, dann ist das auch anders interpretierbar...
Beispielsweise kann die get-Methode bei einer leeren Liste durchaus null liefern, weil man damit unmissverständlich klar machen kann, dass die Liste wohl leer war. Ein entsprechender Swing-Container könnte z.B. trotzdem mit der gleichen Methode gefüllt werden - das Anzeigeelement wäre dann auch einfach nur leer...
Ne andere Sache ist z.B. ein fehlerhaftes Element in eine Liste einzufügen... beispielsweise ein Objekt, was da gar nicht reingehört und später zu Fehlern führen könnte - dann sollte auch ne Exception ausgelöst werden mit dem entsprechenden Hinweis.

In deinem speziellen Fall wäre ich auch für Exception - eine bestimmte Bedingung führt zu einer Ausnahmesituation - schwupp Exception

 

[Bleiglanz]

geht ja auch irgendwie nicht anders

denn INNERHALB der Methode kannst du ja nicht mit der Ausnahme umgehen, also musst du die nach draussen melden

je nach Anwendung hilft manchmal auch

null als Rückgabewert für alle "nicht verarbeitbaren Eingaben"; aber das funktioniert natürlich nur dann, wenn null keinerlei "Bedeutung" hat

 

[L-ectron-X]

Eigentlich ist es doch so, dass man auch innerhalb der Methode prüft, ob Argumente etc. "sauber" sind.
So kann man entsprechend reagieren, um zunächst keine Exception werfen zu müssen.
Nur in Fällen, wo man wirklich nicht vorhersagen kann, was da kommt, bereitet man eine passende Exception vor.

 

[Solour]

naja gibt eben diverse fehlermöglichkeiten nicht...^^
-sowas wie die parameter sind nicht "sauber"
also fehler von dem was da die methode benutzt
-sowas wie ne IOException bei file-access
also fehler von niemandem direkt aber verhindert trotzdem (u.U.)weitere verarbeitung
-sowas wie OutofBoundsException
also fehler in der methode selbst

bei #1 kannst machen wie du magst, aber ner exception kannst ja den parameter-namen/typ mitgeben, damit der user (falls der direkt dahinter sitzt) damit was anfangen kann
u.U. bedeutet (wie ja schon erwähnt) ein return-wert null schon was ganz anderes.. dann auch exception

bei #2 musst du eben schauen ob dein tool evtl. ne abfrage macht obs fortfahren soll (falls möglich) oder nicht
z.B. wenn deine file 30files kopieren soll dann will ich schon evtl. eine bei ders net geht skippen aber evtl. auch alles rückgängig machen...

bei #3 bist du meist sicher eh am ***** weil wenn du damit rechnen würdest das da ne exception kommt würdest du das sicherlich vermeiden

imo ist das also immer ne frage der situation... aber generell sind exception eher guter stil, aber man kann auch in java mit fast allem unsinn treiben..