Exceptions

[Kyuu]

Ich sehe schon, ich hatte eher die C-Assertions im Sinn, als die Assertions aus Java, die sich offenbar darin unterscheiden, dass in C eine fehlgeschlagene Assertion zum sofortigen Abbruch des Programms mit einer entsprechenden Fehlermeldung in der Ausgabe führt, während Java eine Exception wirft. Im Endeffekt ist die Definition der Assertion in beiden Fällen aber natürlich identisch, denn es geht dabei um Bugs im Programmcode und nicht um die Behandlung von fehlerhaftem Userinput.

Jedenfalls habe ich auch schon Leute gesehen, die grundsätzlich Assertions (C/C++) den Exceptions vorziehen, nicht zuletzt aus performancetechnischen Gründen, die natürlich unter Umständen auch gerechtfertigt sein können, aber nicht grundsätzlich und meiner Meinung nach auch nicht in der Regel.

Was ich mit "Strategie" im Sinn hatte, war eher in Richtung wie eure Exceptionhierarchie aussieht, falls eine vorhanden. Ob ihr benutzerdefinierte Exceptions verwendet, diese rigoros von der Basis-Exceptionklasse, je nach Härte von der entsprechenden, vom Framework zur Verfügung gestellten Exceptionklasse (C++: runtime_error vs. logic_error), oder überhaupt nicht ableitet. Wie ihr eure Ausnahmefälle strukturiert, usw.

Wie bereits geschrieben, habe ich schon einiges an Meinungen zu Exceptions gelesen und natürlich gibt es bei all den Unterschieden in der Auffassung und im Einsatz auch Konstanten, über die ein mehr oder weniger allgemeiner Konsens herrscht.

So sollten Exceptions nicht für den Control Flow verwendet werden, nur tatsächliche Ausnahmefälle markieren (die Definition, was ein Ausnahmefall ist, schwankt natürlich), in diesem Zusammenhang auch: nicht für jeden möglichen Ausnahmefall eine eigene Exceptionklasse erstellen, sondern generalisieren und die Details in die Fehlermeldungen verlagern, selbstverständlich immer eine Basis-Exceptionklasse haben, damit die Ausnahmebehandlungsblöcke nicht "explodieren", etc.

Irgendwo habe mal Folgendes gelesen, was ich hoffentlich richtig wiedergebe, da ich den entsprechenden Kommentar nicht mehr finde und es doch schon eine Weile her ist:

Exceptions sollten immer dann geworfen werden, wenn eine fundamentale Annahme verletzt wurde.

Beispiel: Eine Funktion erhält als Parameter ein Objekt der Klasse List und soll "true" zurückgeben falls die Liste mehr Elemente enthält als 50, anderenfalls "false". Die Annahme, die hier gemacht wird, ist dass der Parameter ein Objekt der Klasse List ist. Übergebe ich nun aber einen Nullzeiger, ist diese Annahme verletzt und die Funktion befindet sich in einem Zustand, aus dem sie nicht mit den definierten Regeln zum Aufrufer zurückkehren kann. Die Funktion muss eine Exception werfen.

Was die Frage angeht, ob Exceptions strikterweise zur OOP gehören, so denke ich auch, dass es nicht notwendigerweise der Fall sein muss. Exceptions werden in der Regel in objektorientierten Programmiersprachen geworfen, allerdings hindert nichts daran PODs oder Basistypen zu werfen, wie C++ es eindrucksvoll demonstriert: Java-Leute würden sich davor sträuben, was man dort alles werfen kann.

Naja, jedenfalls sind Exceptions eine relativ komplizierte Sache, wenn man tiefer eintaucht und ihren Sinn verstehen und sie sinngemäß einzusetzen wissen will, meinen eigenen Beobachtungen (die mich einschließen) jedenfalls zur Folge. Einige sind ja immernoch der Meinung Exceptions werden heute noch missverstanden und das sogar auf dem Level von Frameworks wie .NET oder Java. Darüber, dass viele Programmierer nichtmal wissen, was Exceptions sind, geschweige denn, wie man sie richtig einsetzt und sie nicht zuletzt aus diesem Grund meiden, herrscht sowieso ein allgemeiner Konsens, denn dass Exceptions ein mächtiges Werkzeug sind, ist nicht abzustreiten.
In C++ sind Exceptions sowieso ein Fall für sich und es werden dem Entwickler viele Steine in den Weg gelegt, so etwa bei dynamischen Bibliotheken plus Exceptions, so dass ich durchaus den ein oder anderen verstehen kann, wenn er sie ablehnt.