Exceptions

[Jesus_666]

Hmm. Kommt auf die Sprache an.

In Java ganz eindeutig. Aber in Java geht es ohnehin darum, ein gegebenes Problem unter Einsatz möglichst vieler Klassen zu lösen und wenn man nicht jeden zweiten Funktionsaufruf in try/catch wickelt, gilt das als schlechter Stil (so viel übrigens zu C++s häßlichen ifs).

In C++ hab' ich die Dinger nie angefaßt. Aber Ich verwende eh 90% von C++s Fähigkeiten nicht, weil sie arkan, mir nicht bekannt oder auf den ersten Blick komplizierter als eine äquivalente Selbstimplementierung sind.

In PHP benutze ich auch keine. Da jede Funktion alles zurückgeben kann und man mit Assertions oft gerade mal ein Bit an Information liefert (namentlich, daß die aufgerufene Funktion nicht korrekt gearbeitet hat) belasse ich es in der Regel bei return false.

In Objective-C könnte ich wohl welche verwenden, aber die Sprache ist dem Anschein nach zu robust, um häufig welche zu benötigen. Nullpointer sind unproblematisch und bei einem Fehler kommt meistens einfach nil raus und das ist ein gültiger Wert für weitere Funktionen. Ich könnte strikt sein und das Programm abschmieren lassen, wenn es beispielsweise eine Datei nicht finden kann. Nur mach' ich das nicht.

[drunken monkey]

In Java ganz eindeutig. […] wenn man nicht jeden zweiten Funktionsaufruf in try/catch wickelt, gilt das als schlechter Stil (so viel übrigens zu C++s häßlichen ifs).

...

Das habe ich bisher weder irgendwo gesehen noch gehört. o_O" Im Regelfall genügen doch in den meisten Funktionen ein bis zwei solcher Blöcke, unterschiedliche Fehler aus den einzelnen Aufrufen/Statements kann man zur Not ja meist auch am Exception-Typ erkennen. Also ich weiß jedenfalls nicht, woher du das hast, scheint mir auch im Zusammenhang mit dem Rest des Satzes mehr ein Vorurteil zu sein.
Und in C (i.e.: bei der Fehlercode-Zurückliefer-Methode) kommt man um das händische Prüfen jedes einzelnen Rückgabewertes ja eindeutig nicht herum, ohne potenzielle Fehlerquellen im Code zu lassen.

(Ahja, und es ist zumindest für mich nicht ersichtlich, worauf sich dein erster Satz im Zitat bezieht. *kratz*)

[Jesus_666]

Das habe ich bisher weder irgendwo gesehen noch gehört. o_O" Im Regelfall genügen doch in den meisten Funktionen ein bis zwei solcher Blöcke, unterschiedliche Fehler aus den einzelnen Aufrufen/Statements kann man zur Not ja meist auch am Exception-Typ erkennen.

...

Nur dann, wenn ein Fehler in einer aufgerufenen Methode bedeutet, daß die komplette aufrufende Methode nicht mehr funktioniert. Wenn dem nicht so ist, hat man kleine Blöcke mit try/catch(/finally) drumrum. Wenn das öfters vorkommt, kann der Code beeindruckend häßlich werden. Letztenendes macht man im Wesentlichen das Gleiche wie bei C(++), nur daß man statt Fehlerkonstanten Aufrufe von Methoden der Exception hat und sich Sprünge spart, falls doch die ganze Methode ruiniert wird.

(Ahja, und es ist zumindest für mich nicht ersichtlich, worauf sich dein erster Satz im Zitat bezieht. *kratz*)

...

Darauf, ob ich Exceptions verwende.

[Mog]

Ach, asserts mit Exceptions zu vergleichen ist doch schon fast etwas unhuebsch. Die Idee ist ja doch eine Andere: Bei Exceptions ist der Fehlerfall Teil des Ergebnisses, was bei Asserts wiederum nicht der Fall ist.

Beides hat seine Daseinsberechtigung. Dementsprechend mische ich auch beides. So verwende ich Asserts in erster Linie zur Flusskontrolle, während ich Exceptions zur Berichterstattung von Fehlern, mit der Umwelt, verwende.

Der Rest ergibt sich eigentlich genau hier heraus.


Was für Fehler ich nun per Exceptions, oder Return-Wert erstatte, kommt in erster Linie darauf an, was ich gerade mache. In meinem Hauptprojekt, beispielsweise, verwende ich kaum eine Exception aktiv. Fast alle Grundbibliotheken, die ich verwende, werfen keine Exceptions, und die Fehler die, in den einzelnen Phasen meines Programmes auftreten können, müssen in der Regel ohnehin geordnet angezeigt werden. Ungewollte Zustände müssen zwanghaft zum Abbruch führen. Genau so verwende ich meine API nie so, als dass man sich mit Exceptions etwas sparen würde. Ganz im Gegenteil: Dort wo sie schoen anzuwenden wären, würde ich meinen Usern damit das Leben schwer machen.

Hingegen werde ich allerdings demnächst wohl alle fopen-calls aus meinen Plugins heraus schreiben, um auf etwas Exception-werfendes umzusatteln. Zur Zeit sind da nämlich einfach keine Checks, ob ein Call nun gut geht, oder eben nicht. Wenn man so herum zu wenig Speicherplatz hat, wird das Programm einfach nur sterben, ohne, dass irgend etwas berichtet wird. Da ist an dann doch besser dran, wenn man gleich auf etwas abstrahierenderes umsteigt, als wenn man sich das Leben unnötig, mit 1000 if-abfragen, schwer macht. Die klassische C-Alternative, um sich die ganzen Abfragen zu sparen, passt mir zu wenig in den restlichen Code. ^^"


\Jesus
Gerade Stream-Operationen sind doch ein gutes Beispiel, wie man Exception anwenden sollte. Bei einheitlichen APIs, mit guten Exceptions, spart mans ich definitiv etwas.

Btw liest sich der lange Post von dir so, als wuerdest du einen Fisch haben wollen. :P

Und in C (i.e.: bei der Fehlercode-Zurückliefer-Methode) kommt man um das händische Prüfen jedes einzelnen Rückgabewertes ja eindeutig nicht herum, ohne potenzielle Fehlerquellen im Code zu lassen.

...

Denk mal etwas Zeigerlastiger. :P

[drunken monkey]

Denk mal etwas Zeigerlastiger. :P

...

Was willst du mir damit sagen? ^^"
Wenn ich zeigerlastiger denke, denke ich: Fehlerfall => return NULL; => Segmentation fault => $ gdb … # STIIIIIIRB!!!!!. <__<

[R.D.]

In Java ganz eindeutig. Aber in Java geht es ohnehin darum, ein gegebenes Problem unter Einsatz möglichst vieler Klassen zu lösen und wenn man nicht jeden zweiten Funktionsaufruf in try/catch wickelt, gilt das als schlechter Stil (so viel übrigens zu C++s häßlichen ifs).

...

Ist das so? Hier lernen wir, das wir möglichst wenig damit arbeiten sollen und eben nur die checked fangen, alles anderen ist schlechter Code oder unglückliche Umstände.
Ich wüsste auch nicht warum sich einfache abfragen in einen Try-Block packen soll, wenn ich doch schon mit dem If den Fehler gefangen habe.

[Jesus_666]

Es ging ja darum, daß das if unglaublich häßlich sei und daß Exceptions uns das ersparen sollten.

[Kyuu]

Uh Exceptions... Leider kann ich nur von Java berichten und was ich da gelernt habe ließ mich genau auf die Fragen stoße die du die gestellt hast: "Welchen Sinn machen sie?" In Java sind ja so gut wie alle Exceptions bereits vorhanden und eigene lohne sich imho nur für das hochpropagieren oder bei den erwähnten komplexen Rekursionen.
Ansonsten finde ich, das es den Code unnötig auf bläht.

Ich weiß nicht wie es in C++ ist, aber in Java gibt es ja sowieso checked und uncheked Exceptions, also solche die gefangen werden müssen und solche die nicht gefangen werden müssen. So wird man in IDE's soweiso sofort darauf aufmerksam gemacht das man hier einen Try-Block benötigt oder aber die Exception propagiert.

...

Wenn ich das sagen darf: Du denkst hier falsch. Du solltest dir nicht die Frage stellen, ob Exceptions Sinn machen (bzw. welchen Sinn), sondern wann sie Sinn machen und wie man sie sinngemäß einsetzt. Exceptions sind ein mächtiges Werkzeug um deine Programme verlässlicher und wartungsfreundlicher zu machen, in dem Sinn, dass die Fehlerfindung, sowie die Fehlerbehandlung extrem vereinfacht wird im Vergleich zu allen Ansätzen bevor Exceptions eingeführt wurden.

Ganz unabhängig von der Sprache teilst du deine Ausnahmefälle in zwei Kategorien auf:

Ausnahmefälle von denen dein Programm sich erholen kann: Das sind alle Fehler, die mit der Korrektheit deines Programms nichts zu tun haben und Quellen wie etwa fehlerhaften Userinput, fehlende Dateien, Datenbankfehler, usw. haben. Das sind die checked Exceptions in Java.

Und Ausnahmefälle von denen es sich nicht erholen kann: Diese sind grundsätzlich Bugs in deinem Programm (welchen Sinn würde es machen, sich von einem Bug zu erholen? Das würde den Bug nur verschleiern und dein Programm inkonsistent machen), aber auch fatale wie ein erschöpfter Heap oder Vergleichbares. Das sind die unchecked Exceptions in Java, die alle von RuntimeException ableiten. In der Regel werden diese Exceptions viel öfter geworfen als die aus der oberen Sparte, was auch ein Grund ist, wieso du sie nicht in deiner API deklarieren musst.

Ehrlich gesagt finde ich auch nicht wirklich Gefallen daran gezwungen sein zu müssen checked Exceptions zu behandeln, aber das ist eher bedingt durch die Faulheit zu der C++ verleitet und hat nichts damit zu tun, dass ich diesen Zwang sinnlos finde. Im Gegenteil, ich finde es ist gerechtfertigt und macht das Programm viel konsistenter, beispielsweise im Gegensatz zu C++-Programmen/Bibliotheken, in denen man oft nicht weiß, ob, welche und bei welchem Input Exceptions geworfen werden. Dass C++ erlaubt mit allem zu werfen, was einem unter die Finger kommt, habe ich ja bereits erwähnt. Also ja, Javas Ideologien blähen den Code durchaus auf, aber in einem für Java akzeptablen Rahmen (bei sinngemäßem Einsatz) und bestimmt nicht unnötigerweise.

Ich wüsste auch nicht warum sich einfache abfragen in einen Try-Block packen soll, wenn ich doch schon mit dem If den Fehler gefangen habe.

...

Du hast dich wahrscheinlich nur unglücklich ausgedrückt, aber eine Exception kannst du nicht mit einem If-Block abfangen.

Wenn ich nochmal auf diesen Artikel verweisen darf und das Problem dort mit Int32.Parse(). Das ist zwar C#-bezogen, aber die Problematik dort ist sprach-/frameworkunabhängig, nämlich: Exceptions sollten nicht für die Flusskontrolle verwendet werden. Solltest du auf so etwas stoßen, darfst du es als Designfehler abstempeln und die API-Designer darin kritisieren, dass es ein Boolean-Rückgabewert auch getan hätte und das viel eleganter.

Ach, asserts mit Exceptions zu vergleichen ist doch schon fast etwas unhuebsch. Die Idee ist ja doch eine Andere: Bei Exceptions ist der Fehlerfall Teil des Ergebnisses, was bei Asserts wiederum nicht der Fall ist.

Beides hat seine Daseinsberechtigung. Dementsprechend mische ich auch beides. [...]

...

Klar. Auf Assertions würde ich auch nicht verzichten, egal ob ich gerade Exceptions verwende, oder nicht. Wie der Name bereits sagt, sind sie eine Zusicherung an die Korrektheit des Programms und beim DbC-Pattern sowieso nicht wegzudenken.

@affe (wenn ich dich so nennen darf ^^):

Der klassische C-Ansatz ist doch eher, dass der Rückgabewert entweder in einem gültigen oder in einem ungültigen Wertebereich liegt, worauf man prüft, und der Fehlercode in einer globalen, "errno"-ähnlichen Variable gespeichert wird. Natürlich muss man immernoch den Fehlercode interpretieren, aber das kann man generalisiert erledigen.

Ansonsten komme ich im Moment auch nicht darauf, was Mog mit "denk mal etwas zeigerlastiger" gemeint hat, wenn er nicht gerade den Umstand meinte, dass die Überprüfung schwarz-weiß ist. ^^

[R.D.]

@Kyuu

Ich hab mir den Artikel mal durchgelesen (warum nicht schon früher weiß ich auch nicht). Ist sehr interessant und offenbarend für mich gewesen. In der FH hier hatte man uns das Ganze so beigebracht das man einen Try-Block macht und in DIESEM ein Abfrage macht und die Exception wirft. Ich fand eben das immer irgendwie fraglich.

[Kyuu]

Also sowas wie

Code (C++):

 
void MeStupid() {
    try {
        if (SomeFunc() == false) {
            throw SomeFuncFailed();
        }
    } catch (const SomeFuncFailed& e) {
        GoNuts();
    }
}
 

?

[drunken monkey]

Wenn ich nochmal auf diesen Artikel verweisen darf und das Problem dort mit Int32.Parse(). Das ist zwar C#-bezogen, aber die Problematik dort ist sprach-/frameworkunabhängig, nämlich: Exceptions sollten nicht für die Flusskontrolle verwendet werden. Solltest du auf so etwas stoßen, darfst du es als Designfehler abstempeln und die API-Designer darin kritisieren, dass es ein Boolean-Rückgabewert auch getan hätte und das viel eleganter.

...

Naja, ein Boolean-Rückgabewert geht da eben kaum, weil die Methode bereits ein Integer zurückgeben soll. Dass es keine einfache Möglichkeit gibt/gab (in Java ja bis heute genauso), vorher die Gültigkeit zu überprüfen (am besten auch noch, ohne dadurch die gleiche Arbeit zweimal zu erledigen, irgendwie will man ja doch noch Performance im Auge behalten) ist natürlich ungünstig, aber ich wüsste nicht wirklich, was die Methode bei einem ungültigen String machen sollte, außer eine Exception zu werfen. Und eine gute Möglichkeit, vorher die Gültigkeit zu testen, fällt mir auch spontan nicht ein, wenn man nicht für jedes Parsing ein eigenes Parser-Objekt erzeugen will.
(Disclaimer: All das bezieht sich auf Javas Integer.parseInt(), mit der implziten Annahme, dass das in C# praktisch genauso ausschauen wird.)

@affe (wenn ich dich so nennen darf ^^):

Der klassische C-Ansatz ist doch eher, dass der Rückgabewert entweder in einem gültigen oder in einem ungültigen Wertebereich liegt, worauf man prüft, und der Fehlercode in einer globalen, "errno"-ähnlichen Variable gespeichert wird. Natürlich muss man immernoch den Fehlercode interpretieren, aber das kann man generalisiert erledigen.

...

Ja, meinte ich ja, halt irgendeinen speziellen Rückgabewert zurückliefern, ungeachtet dessen ob der jetzt direkt den konkreten Fehler angibt oder auch noch eine globale Variable (= inhärentes x__X) benötigt. Jedenfalls muss man jeden Aufruf in ein if hüllen – oder alle Rückgabewerte sammeln (bei nicht aufeinander aufbauenden Aufrufen) und dann eine Riesen-if-Party am Ende veranstalten. *kratz*

Und: Ja, darfst du. XD

Also sowas wie
[…]
?

...

Habe ich auch schon gesehen, und in manchen komplizierteren Fällen ergibt's sogar Sinn. Als bloßen Workaround für GOTOs aber natürlich absolut grauslich. x__X

[Kyuu]

Naja, ein Boolean-Rückgabewert geht da eben kaum, weil die Methode bereits ein Integer zurückgeben soll. Dass es keine einfache Möglichkeit gibt/gab (in Java ja bis heute genauso), vorher die Gültigkeit zu überprüfen (am besten auch noch, ohne dadurch die gleiche Arbeit zweimal zu erledigen, irgendwie will man ja doch noch Performance im Auge behalten) ist natürlich ungünstig, aber ich wüsste nicht wirklich, was die Methode bei einem ungültigen String machen sollte, außer eine Exception zu werfen. Und eine gute Möglichkeit, vorher die Gültigkeit zu testen, fällt mir auch spontan nicht ein, wenn man nicht für jedes Parsing ein eigenes Parser-Objekt erzeugen will.
(Disclaimer: All das bezieht sich auf Javas Integer.parseInt(), mit der implziten Annahme, dass das in C# praktisch genauso ausschauen wird.)

...

Man kann auch out-Parameter benutzen:

Code (C++):

 
class Int32 {
public:
    // ...
    bool Parse(const string& s, int32& out) {
        // ...
    }
    // ...
};
 

Und diese sind alles andere als unüblich.

Habe ich auch schon gesehen, und in manchen komplizierteren Fällen ergibt's sogar Sinn. Als bloßen Workaround für GOTOs aber natürlich absolut grauslich. x__X

...

Wenn man die Exception nicht fängt und nach außen propagieren lässt - und nur dann - wäre es sinnvoll, imo. Eleganter wäre es sowieso, wenn SomeFunc() selbst wirft, aber selbstverständlich kann es sein, dass diese zu irgendeiner externen Bibliothek gehört, die aus irgendeinem Grund keine Exceptions nach außen lässt, oder sie überhaupt nicht verwendet.

[drunken monkey]

Man kann auch out-Parameter benutzen:

...

Ah, OK, deswegen eben mein Disclaimer. In Java gibt's die ja nicht.
In C# wäre das dann wohl wirklich die deutlich bessere Lösung.

[R.D.]

Also sowas wie

Code (C++):

 
void MeStupid() {
    try {
        if (SomeFunc() == false) {
            throw SomeFuncFailed();
        }
    } catch (const SomeFuncFailed& e) {
        GoNuts();
    }
}
 

?

...

exakt so. Aber gut das ich hier was gelernt hab, jetzt kann ich das bei der Semesterausgabe anwenden.