"vollständige" Resultat Rückgabe

[beginner99]

Hallo,

nehmen wir an Klasse A ruft eine methode in Klasse B auf, die dann true (=erfolgreich) oder false zurückgibt und diese Information wird dann in A weiterverarbeitet (unter anderem am User anzeigen, ob erfoglreich oder nicht)

Nun ist es aber so, dass es 2 klar definierte Gründe gibt (Status der Klasse B), wieso die Methode nicht erfolgreich war und den Grund für das scheitern möchte man ja auch an Klasse A zurückgeben. Nur wie?
Eigene Klasse, "success object" oder deutet das ganze einfach auf ein bad design hin?

 

[max40]

spontan würde ich sagen das man statt boolean enum types verwendet!

Enum Types (The Java™ Tutorials > Learning the Java Language > Classes and Objects)

 

[ARadauer]

, die dann true (=erfolgreich) oder false zurückgibt

wieso die Methode nicht erfolgreich war

vielleicht nicht boolen zurück geben sondern ein Ergebnis Objekt mit der Eigenschaft erfolgreich oder nicht und eine beschreibung...


oder eine Exception werfen, wenns nicht erfolgreich war?

 

[bygones]

vielleicht nicht boolen zurück geben sondern ein Ergebnis Objekt mit der Eigenschaft erfolgreich oder nicht und eine beschreibung...


oder eine Exception werfen, wenns nicht erfolgreich war?

damit der aufrufer sich auch noch um diese Exception kuemmern muss... nene lieber nicht.

Ein eregnisobjekt mit einem enum denke ich waere passender

 

[maki]

Das ist die alte Diskussion Rückgabewerte vs. Exceptions, wobei ich mich in so einem Fall eher an Exceptions halten würde.

 

[bygones]

Das ist die alte Diskussion Rückgabewerte vs. Exceptions, wobei ich mich in so einem Fall eher an Exceptions halten würde.

da bin ich echt ueberrascht ;-)

wieso ? wenn es 2 Gruende geben kann weswegen die Methode scheitert - sollen dann 2. versch. Exceptions genommen werden ?

ich bin und bleib gegen Exception loesung und sehe einen StatusRueckgabewert - wie auch immer verpackt - also besser an !

 

[maki]

da bin ich echt ueberrascht

Vielleicht hab ich den TS auch nur falsch verstanden
Falls es darum geht, Fehler/Ausnahmen zu behandeln, bin ich ganz klar auf der "Exception Seite".
Falls es darum geht zu validieren (ohne Daten zu ändern), könnte man auch mit Rückgabewerten arbeiten.

Hab mir angewöhnt dass Methoden, welche Seiteneffekte haben (Speichern in DB, ändern von Daten, etc. pp.) nur void als Rückgabewert haben, sonst kommt noch jemand auf die Idee die Methode mehrmals auszuführen, nur um das Ergebnis zu erhalten... falls etwas schiefläuft (zB. nicht erfüllte Preconditions), gibt es eine Exception.
Wobei natürlich Rückgabewerte anstatt void auch möglich wären (vermieden werden sollte zB. unbedingt ein Getter der Seiteneffekte hat), aber für Ausnahmefälle nehme ich prinzipiell Exceptions.

 

[beginner99]

@maki

ja du hast mich wohl falsch verstanden. Mir fällt jetzt aber gerade nur folgende Analogie ein.

Du hast en Klasse Auto und rufst nun die Methode anfahren() auf und die methode gibt zurück ob es funktioniert hat.
Scheitern kann sie, wenn der Motor nicht an ist, der Gang nicht eingelegt, die Handbremse ist angezogen,...
All diese Fälle sind nichts untpyisches und normal, als kein besonderer zustand.
(man sollte das jetzt nicth zu sehr in die realitöt übetragen)

 

[maki]

Also wenn ich mein Auto starten will und es nicht geht, sehe das nicht als Normal an das wäre imho 'ne Ausnahme.
Besonders weil anfahren() anscheinend interne Zustände ändert, wäre da ein void angebracht und falls was nicht geht, eine Exception.
Aber das ist nur meine Meinung...