Exception versus Rückgabeparamter

[TomTank]

Hallo Leute,

Ich bin am überlegen wann wirklich eine Exception und wann ein Rückgabeparmeter gesetzt werden soll. Beispiel

Funktion ( nur symbolisch art ):

function Datenbank::Connect( config ) {
// verbinde mit Datenbank
// werfe exception oder gebe rückgabeparameter
}

Natürlich ist mir der entscheidende Unterschied schon klar. Exception kann von einer höheren Ebene abgefangen werden. Rückgabeparameter wird nur an die nächst höhere Ebene zurückgegeben.

Allerdings könnt man doch auch den Rückgabewert bis zur oberste Ebene zurückgeben. Deshalb meine ernsthafte überlegung wann ganz konkret ist eine Exception einem Rückgabeparameter vorzuziehen bzw. wann ist ein Rückgabeparameter sinnvoller?

Danke
Markus

 

[Andgalf]

Imho sind exceptions nicht zur Programmsteuerung da. Also solltest du den parameter verwenden und eine Exception nur dann werfen, wenn wirklich was unvorhergesehenes passiert.

Ich weiß, das es in java das Konstrukt der "checked exceptions" gibt, aber da scheiden sich ja auch die Geister. Ich bin kein Fan von checked exceptions ... aber darüber gibt es schon genug diskussionen, wenn dich das näher interessiert einfach mal nach danach googeln.

Ich verwende im normalfall nur unchecked exceptions.

 

[bygones]

Deshalb meine ernsthafte überlegung wann ganz konkret ist eine Exception einem Rückgabeparameter vorzuziehen bzw. wann ist ein Rückgabeparameter sinnvoller?

nie und immer

(um auch mal die moeglicherweise beruehmten Ausnahmen unter den Tisch zu kehren)

 

[jgh]

nie und immer

(um auch mal die moeglicherweise beruehmten Ausnahmen unter den Tisch zu kehren)

alberne Aussage! Wenn ich bspw auf eine Datei zugreifen will und erwarte eine File-Object zurück, dann ist es doch weitaus sinnvoller mir eine FileNotFoundException zu schmeißen, als ein File-Object das null ist. Aber gut...jedem seine Meinung, ich will und werde mich nicht an einer evtl. Diskussion beteiligen.

Imho hängt es vom Anwendungsfall ab...

 

[DanZ]

alberne Aussage! Wenn ich bspw auf eine Datei zugreifen will und erwarte eine File-Object zurück, dann ist es doch weitaus sinnvoller mir eine FileNotFoundException zu schmeißen, als ein File-Object das null ist. Aber gut...jedem seine Meinung, ich will und werde mich nicht an einer evtl. Diskussion beteiligen.

Imho hängt es vom Anwendungsfall ab...

Das ist hier in Mode irgendwelche klar positionierten Statements in den Raum zu schmeißen ohne dann was mit der Diskussion zu tun haben zu wollen was?
Das ist doch ganz klar eine Semantikfrage... nämlich ob null - also Datei nicht gefunden, nicht definiert, wie auch immer - zu den erwarteten Ergebnissen dieser Methode gehört oder nicht. Wie auch immer.

Grundsätzlich gilt meiner Meinung nach: Jede Methode definiert anhand ihres Rückgabetyps und ihrer Aufgabe (on nun implizit oder dokumentiert) einen Menge an erwarteten Ergebnissen. Kannst du ein Element aus dieser Menge zurückgeben nutze "return", kannst du aus irgendwelchen Gründen kein Element dieser Menge zurückgeben dann solltest du eine Exception werfen. Das hängt alles auch immer vom Kontext ab in dem du das ganze einsetzen willst. Zum Beispiel wirst du nicht um jedes "getConfigurationValue" ein try-catch Block bauen wollen.
In Außnahmefällen ist es denke ich aber auch legitim Exceptions zur Programmsteuerung zu verwenden. Nämlich dann, wenn sagen wir mal 99,5% der Ergebnisse mit einem einfachen Rückgabetyp abgedeckt werden kann aber um alle theoretischen Möglichkeiten abzudecken ein viel komplexerer Rückgabetyp erforderlich wäre. Heißt ja schließlich auch "Außnahme" und nicht "Fehler".

 

[nillehammer]

Ich DanZ's Post so voll unterschreiben. Und zu Deinem konkreten Anwendungsfall. Wenn Deine connect-Methode (was ist das eigentlich für eine Syntax?) aus irdend einem Grund keine Connection zurückliefern kann, dann sollte sie nicht einfach null zurück geben. Erstens musst Du im Client-code dann immer auf !=null überprüfen. Und zweitens hat der Client dann keine Informationen, was da schief gegangen ist (Fehler in config?, Datenbank down?, Login-Informationen falsch?). Solche Informationen kann man in einer Exception sehr schön weiterreichen. Und zur Frage checked oder unchecked, nimm unchecked.

 

[maki]

alberne Aussage! Wenn ich bspw auf eine Datei zugreifen will und erwarte eine File-Object zurück, dann ist es doch weitaus sinnvoller mir eine FileNotFoundException zu schmeißen, als ein File-Object das null ist. Aber gut...jedem seine Meinung, ich will und werde mich nicht an einer evtl. Diskussion beteiligen.

Imho hängt es vom Anwendungsfall ab...

Eine Diskussion beginnen, um dann während der Diskussion zu behaupten man würde sich an keiner Diskussion beteiligen... DAS ist albern.

 

[freez]

Ich weiss, dass in einigen Bereichen bewusst auf null's verzichtet wird, um die Fehlersuche bei NullPointerExceptions zu vermeiden, aber wenn dein Rückgabewert auch beinhaltet, dass er null sein darf und auch klar definiert ist warum, dann kann man das durchaus machen. Man denke hier z.B. an Map.get(key) ... Hier ist ganz klar: null = key/value nicht vorhanden.

"Exceptions" sind Ausnahmen und dürfen meiner Meinung nach bewusst so eingesetzt werden (auch zur Programmsteuerung) ... aber nur wenn es eine Ausnahme ist, wenn eine Exception fliegt.

Den Post von DanZ möchte ich hiermit voll und ganz bestätigen.

 

[bygones]

es geht hier nicht darum dass man nie eine Exception werfen soll. Natuerlich, wenn der Programmablauf nicht weiterzufuehren ist, und ein unvorgesehenes Ereignis eingetreten ist, so mag eine Exception vertretbar sein.

Aber einen gueltigen ablauf durch das (nicht) werfen einer Exception zu steuern ist falsch. Bei dem DB bsp mag natuerlich auch eine Exception geschmissen werden, aber nur wenn eben eine ausnahme eingetreten ist...

Wenn ich bspw auf eine Datei zugreifen will und erwarte eine File-Object zurück, dann ist es doch weitaus sinnvoller mir eine FileNotFoundException zu schmeißen

zeig mir bitte eine sinnige Methode fuer dieses Szenario... (und ich red nicht von einem Reader, den du hier nicht erwaehnst) - aber ich vergass ja, du sagst ja nix mehr dazu... soll also zb Files#exists ne FileNotFoundException werfen, wenn es nicht da ist ?

 

[SlaterB]

> soll also zb Files#exists ne FileNotFoundException werfen, wenn es nicht da ist ?
komische Frage, eine Methode die etwas abfragt, kann ja nicht für einen der beiden Fälle (true/ false) eine Exception werfen sollen

noch interessanterer Punkt, Grund für mein Posting:
um diese Methode überhaupt aufrufen zu können, bräuchte es ja ein File-Objekt ohne Exception, damit ist der zitierten Aussage
"erwarte eine File-Object zurück, dann ist es doch weitaus sinnvoller mir eine FileNotFoundException zu schmeißen" bereits widersprochen

new File() usw. wirft keine Exception, der genannte Reader dagegen schon, das sind interessante unterschiedliche Beispiele,
für eigene Programme kann man überlegen ob irgendwo statt File-Rückgabe eine Exception fliegen soll

 

[musiKk]

zeig mir bitte eine sinnige Methode fuer dieses Szenario... (und ich red nicht von einem Reader, den du hier nicht erwaehnst) - aber ich vergass ja, du sagst ja nix mehr dazu... soll also zb Files#exists ne FileNotFoundException werfen, wenn es nicht da ist ?

[c]File[/c] ist natürlich ein ungünstiges Beispiel, da die meisten Methoden nur auf Pfaden arbeiten. Dass [c]exists()[/c] keine Exception werfen sollte, ist ja klar; Exceptions sind ja für Ausnahmesituationen. In diesem Fall wird [c]exists()[/c] benutzt um solche Ausnahmen am besten gar nicht erst auftreten zu lassen. Aber z. B. [c]delete()[/c] sollte eine Exception werfen. Es ist sicher schon vielen passiert, dass sie ein File löschen, ohne auf den Rückgabewert zu prüfen (nicht umsonst prüft z. B. FindBugs darauf). Das Konzept ist ja auch aus C-Zeiten und sollte in einer Sprache mit Exceptions nicht nötig sein.

Davon abgesehen finde ich es in vielen Situationen kritisch, einen Fehler durch die Rückgabe von [c]null[/c] zu kodieren, da man dadurch einen Magic Value enthält. Sobald ein zweiter Fehlerfall dazu soll, funktioniert dieses Konzept sowieso nicht mehr. Mit Exceptions umgeht man das Problem gleich.

 

[maki]

Aber z. B. delete() sollte eine Exception werfen. Es ist sicher schon vielen passiert, dass sie ein File löschen, ohne auf den Rückgabewert zu prüfen (nicht umsonst prüft z. B. FindBugs darauf). Das Konzept ist ja auch aus C-Zeiten und sollte in einer Sprache mit Exceptions nicht nötig sein.

Macht es aber nicht, es gibt nur einen boolean zurück.

Anscheinend sind bestimmte Situationen so wahrscheinlich, dass sie keine Ausnahme rechtfertigen

So einen Rückgabewert nicht zu prüfen ist schlicht ein Programmierfehler, deswegen findet FindBugs den auch.

Die frage des TS verstehe ich so, ob man den Programmfluss durch Exception steuern sollte, und da ist die Aussage "Nie und nimmer" absolut richtig imho, ob man null zurückgibt oder nicht sehe ich da weder als frage noch sonstwie, sondern wurde vom "angeblichen nicht-Diskutierer" als Argument für eine angeblich nicht vorhandene Diksussion eingebracht (super Sache übrigens :autsch.

Man stelle sich folgendes mal vor:

Collection col = ...

try {
  Iterator it = col.iterator;

   while(true) {

     Object element = it.next();

     // do something with element
     ...
   }

} catch (NoSuchElementException ignore) {
}

// more Code
...

 

[bygones]

Aber z. B. [c]delete()[/c] sollte eine Exception werfen. Es ist sicher schon vielen passiert, dass sie ein File löschen, ohne auf den Rückgabewert zu prüfen

diejenigen, die den Rueckgabewert nicht pruefen wuerden auch nicht auf eine Exception pruefen - oder wuerdest hier dann eine checked exception nutzen ?

 

[SlaterB]

nun ja, schon wieder anmerkend, eine ungeprüfte Exception ist was anderes als ein ungeprüfter Rückgabewert?!,
Abbruch des Programmflusses zu einer höheren Stelle, Log-Ausgabe oder sonst wie bemerkbares Fehlverhalten

das ist doch die Natur der extra unchecked Exceptions, dass man sie nicht prüfen muss??

Die frage des TS verstehe ich so, ob man den Programmfluss durch Exception steuern sollte, und da ist die Aussage "Nie und nimmer" absolut richtig imho,

kommt drauf an, ob man die Fehlersituationen als Teil des Programmflusses ansieht oder nicht

aus dem Beispiel

function Datenbank::Connect( config ) {
// verbinde mit Datenbank
// werfe exception oder gebe rückgabeparameter
}

sehe ich keinen Grund für eine Exception außer Fehlersituation,
was nicht heißt dass man Exceptions nicht in anderen Fällen wirklich als eine Art GOTO einsetzen kann,
das ist dann sicher fragwürdig

 

[jgh]

@ maki
*lächelnd* du hast Recht, ich habe Ruhe
Von einem Moderator erwarte ich grundsätzlich aber nicht so ein infantiles Verhalten!

btw mein Bsp mit File und FileNotFoundException war natürlich nicht passend gewählt, nebenbei schrieb ich aber auch..."Aber gut...jedem seine Meinung

Nur mal so als Einwurf, bevor die nicht vorhandene Diskussion tatsächlich beendet wird (und ich mich nicht mehr amüsieren kann), wenn checked Exceptions soooooooooooooooooo schlimm sind, warum werden sie denn in den Core-Klassen von Java genutzt. Evtl. sind/waren die Entwickler von sun, bzw. oracle nicht so schlau, wie es hier einige vorgeben zu sein.

 

[SlaterB]

> Evtl. sind/waren die Entwickler von sun, bzw. oracle nicht so schlau, wie es hier einige vorgeben zu sein.

dass die Entwickler von Sun nicht schlau waren ist sicher einhellige Meinung,
was möchtest du da drehen?

" wenn Sch.. so schlecht schmeckt, warum fressen so viele Fliegen sie täglich?"

 

[jgh]

" wenn Sch.. so schlecht schmeckt, warum fressen so viele Fliegen sie täglich?"

...dass Sie keine Nachrichten schreiben, die obszön, vulgär, ...

Was soll man dazu noch weiter sagen...Den Bock zum Gärtner gemacht!
[ot]die intention (wenn auch für einen "höheren" Zweck) ist doch folgende, warum frisst du/ich/wir keine sch..... wenn das nicht widerlich ist, dann frage ich mich ernsthaft was denn obszön und vulgär ist

und nein, da sollte kein Smiley hin...ich finde so ein Verhalten für einen Moderator unwürdig.
[/ot]

 

[SlaterB]

es ging hier 1. um einen höheren Zweck für den mir 2. kein anderes markantes Sprichwort einfiel,
und 3. falls von dir ernst gemeint, ich sehe keinen Smily, ist das wohl öfters auftretendes Wort,
das ich allerdings glaube ich bisher nicht verwendet hatte

 

[bygones]

Nur mal so als Einwurf, bevor die nicht vorhandene Diskussion tatsächlich beendet wird (und ich mich nicht mehr amüsieren kann), wenn checked Exceptions soooooooooooooooooo schlimm sind, warum werden sie denn in den Core-Klassen von Java genutzt. Evtl. sind/waren die Entwickler von sun, bzw. oracle nicht so schlau, wie es hier einige vorgeben zu sein.

natuerlich - wer bei Oracle / Sun arbeitet hat automatisch das Super-Duper-Entwickler-Gen in sich und macht nur richtige und gute Sachen.

Ich hoffe in den Forenregeln steht nix von Ironie.

nur weil es Sachen in Java gibt, dir vor zig Jahren (Jahrzehnten) entstanden sind, heisst dass nicht, dass sie a) richtig sind und b) man sie nachmachen sollte.

schau dir zum bsp InfoQ: How to Design a Good API & Why it Matters and, bei dem Joshua Bloch, zur damaligen Zeit ein wichtiger "super-duper-entwickler" bei Sun, erklaert was gute API macht und wo das JDK das mies macht bzw gut macht.... wie gesagt, nur weils im JDK so ist, ists nicht automatisch gut

 

[maki]

@ maki
*lächelnd* du hast Recht, ich habe Ruhe
Von einem Moderator erwarte ich grundsätzlich aber nicht so ein infantiles Verhalten!

Ich erwarte von Leuten, die eine Diskussion anzetteln, auch Argumente zu liefern, und nicht einfach nur ein paar Begriffe in den Raum zu werfen um dann zu sagen "ich diskutiere nicht mit euch!", denn DAS ist kindisch.

btw mein Bsp mit File und FileNotFoundException war natürlich nicht passend gewählt, nebenbei schrieb ich aber auch..."Aber gut...jedem seine Meinung

Du bringst ein schlechtes Beispiel und weil du sagst "jedem seine Meinung" ist es dann wieder ok?

Wenn du nicht diskutieren kannst, dann alss es doch einfach, zwingt dich doch keiner so einen Quatsch hier zu schreiben.

Nur mal so als Einwurf, bevor die nicht vorhandene Diskussion tatsächlich beendet wird (und ich mich nicht mehr amüsieren kann), wenn checked Exceptions soooooooooooooooooo schlimm sind, warum werden sie denn in den Core-Klassen von Java genutzt. Evtl. sind/waren die Entwickler von sun, bzw. oracle nicht so schlau, wie es hier einige vorgeben zu sein.

Schon mal aufgefallen dass das alles vor Jahren passiert ist, und Sun aus Prinzip keine alten Zöpfe abschneidet?

Hier eine Frage für dich: Warum hat keine Java API seit Jahren mehr neue checked Exception definiert?

 

[bERt0r]

Mal ein anderer Punkt, ist nicht ein wesentlicher Vorteil von ORM in Java, dass man sich diese ganzen redundaten und hässlichen try-catch-Klauseln von Connection, Statement und ResultSet bei jeder DB-Aktion spart?

 

[tfa]

Mal ein anderer Punkt, ist nicht ein wesentlicher Vorteil von ORM in Java, dass man sich diese ganzen redundaten und hässlichen try-catch-Klauseln von Connection, Statement und ResultSet bei jeder DB-Aktion spart?

Unter anderem. Die ORM-Mapper mappen nämlich nicht nur persistente Objekte, sondern auch die "checked" SQLException in diverse "unchecked" ORM-spezifische Exceptions.

 

[DanZ]

Mal ein anderer Punkt, ist nicht ein wesentlicher Vorteil von ORM in Java, dass man sich diese ganzen redundaten und hässlichen try-catch-Klauseln von Connection, Statement und ResultSet bei jeder DB-Aktion spart?

Das hällst du auch nur für einen Vorteil, solange niemand deine Leistung mit SVN Tools anhand von geschriebenen Codezeilen beurteilt

 

[SlaterB]

jede Checked Exception oder sonst wie BoilerCode-API kann man auch mit eigenen Hilfsklassen effektiv umwandeln,
dafür brauchst keine MBs an APIs, auch wenn die natürlich diesen netten positiven Nebeneffekt haben, falls gut gemacht

unverzichtbar eigentlich, aber hier im Forum nicht zu schreiben:

    /**
     * Thread.sleep() mit try/catch. Ignoriert InterruptedException.
     * 
     * @param millis
     */
    public static void sleep(int millis)
    {
        try
        {
            Thread.sleep(millis);
        }
        catch (InterruptedException e)
        {
            //
        }
    }

 

[Andgalf]

solange niemand deine Leistung mit SVN Tools anhand von geschriebenen Codezeilen beurteilt

Ich hoffe doch, dass es sowas tatsächlich nicht mehr gibt !!

 

[jgh]

...Du bringst ein schlechtes Beispiel und weil du sagst "jedem seine Meinung" ist es dann wieder ok?...

oh nein,natürlich nicht. Wie dumm von mir, dass ich es damit auf sich bewenden lassen wollte!!!
Schande über mein Haupt, geteert und gefedert sollte ich werden...oh große maki, ich entschuldige mich 100x für mein schlechtes Beispiel und will nur noch deine Meinung gelten lassen!
Was kann ich noch tun um mein arges Fehlverhalten zu entschuldigen?

...
Wenn du nicht diskutieren kannst, dann alss es doch einfach, zwingt dich doch keiner so einen Quatsch hier zu schreiben...

ne, zwingen tut mich keiner...aber motivieren kannst du mich. Wenn mein Post, bzw. ich 2x von einem Moderator in zwei verschiedenen Antworten erwähnt wird, kann ich leider nicht anders.

...Ich erwarte von Leuten, die eine Diskussion anzetteln, auch Argumente zu liefern, und nicht einfach nur ein paar Begriffe in den Raum zu werfen um dann zu sagen "ich diskutiere nicht mit euch!", denn DAS ist kindisch...

Ich erwarte wenn man mich zitiert, dass man mich auch korrekt zitiert.
Keine Diskussionsgrundlage...wer zitieren will, sollte das erstmal lernen und nicht irgendwelche Interpretationen als wörtliche Rede deklarieren! Um das klar zu stellen: "Ich diskutiere nicht mit euch!" ist kein Zitat von mir, sondern eine Unterstellung!

Zum Thema könnte ich auch noch was sagen, aber das lass ich lieber ...
Der eine schreibt über den Geschmack von Kot, der andere zitiert mich wissentlich falsch!

Ich kapituliere vor diesen Moderatoren.

 

[bERt0r]

Ich hoffe doch, dass es sowas tatsächlich nicht mehr gibt !!

Wenn doch, programmier ich ab jetzt nur mehr in Assembler.