Exceptions Considered Harmful
 
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern

"Exceptions Considered Harmful": Ein hypothetischer Artikel, der aufzeigt, dass und warum Exceptions, wie sie z. B. in den Programmiersprachen SpracheCpp und SpracheJava als Sprachmittel zur Verfügung stehen, grundsätzlich von Übel sind. Analog zu GoToConsideredHarmful wird es dann wie mit der Frage GoToJaOderNein natürlich trotzdem immer noch Leute geben, die bis zum Sanktnimmerleinstag EinGutesExceptionBeispiel suchen.

Für den gegenteiligen Standpunkt vergleiche ExceptionsConsideredUseful.

Usenet-Erstnennung von "Exceptions Considered Harmful" laut Google am 11. November 1993: http://groups.google.com/groups?selm=gurgleCGCD8I.9D3@netcom.com.

Immerhin, es gibt bereits einen Artikel CheckedExceptionsConsideredHarmful (von ca. Anfang 2002).

"Exception handling considered harmful", Diskussion in Usenet-Gruppe comp.object, April 2002, http://groups.google.com/groups?q="exception+handling+considered+harmful".

"People have asked why I don't like programming with exceptions. [...]", JoelSpolsky, Oktober 2003 (Joel on Software), http://www.joelonsoftware.com/items/2003/10/13.html + http://www.joelonsoftware.com/items/2003/10/15.html.

"A Pragmatic Look at Exception Specifications", Herb Sutter, July 2002, http://www.gotw.ca/publications/mill22.htm.

"Standard Features Missing From VC++ 7.1. Part I: Exception Specifications", Nemanja Trifunovic, April 2004, http://www.codeproject.com/cpp/stdexceptionspec.asp.

"Cleaner, more elegant, and wrong", Raymond Chen, April 2004 (MSDN Blogs), http://blogs.msdn.com/oldnewthing/archive/2004/04/22/118161.aspx.

"Cleaner, more elegant, and harder to recognize", Raymond Chen, Januar 2005 (MSDN Blogs), http://blogs.msdn.com/oldnewthing/archive/2005/01/14/352949.aspx.

"Making Wrong Code Look Wrong", JoelSpolsky, Mai 2005 (Joel on Software), http://www.joelonsoftware.com/articles/Wrong.html.

"Google C++ Style Guide: We do not use C++ exceptions.", August 2008, http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Exceptions.

"Why Exceptions Suck", S. Johnson, Juli 2008, http://www.ckwop.me.uk/Why-Exceptions-Suck.html.

"Exceptions are Bad™", J. Wesley-Smith, Mai 2011 (Atlassian Blogs), http://blogs.atlassian.com/2011/05/exceptions_are_bad/.

"Dennis being all subjective again - Exceptions considered harmful", D. Gurzhii, April 2012 (MSDN Blogs), http://blogs.msdn.com/b/dennisg/archive/2012/04/28/exceptions-considered-harmful.aspx.

"Why does Go not have exceptions?", The Go Programming Language - FAQ, September 2012, http://golang.org/doc/go_faq.html#exceptions.

"Exception Handling: The Case Against", Andrew P. Black ( http://web.cecs.pdx.edu/~black/), 1982, http://web.cecs.pdx.edu/~black/publications/Black D. Phil Thesis.pdf. Auszug: "[...] Chapter 8 - CONCLUSION [...] 8.1 Exception Handling is Unnecessary [...] 8.2 Exception Handling is Undesirable [...] Similarly [as with mathematics], a programming language should be constructed with the aim of making programs written in it easy to understand and reason about. Simplicity is one desirable property of such a language. Thus great care should be taken before any nonessential feature is included. Exception handling is just such a nonessential feature. It is nothing more nor less than an additional control structure for programing languages. [...] The reason that exception handling mechanisms are undesirable is that, where as they are irrelevant to the correction of erroneous programs, the difficulties they introduce are very real. Rather than making it easier to write reliable programs, they make it more difficult. [...]".

Ursprünglich von VolkerGlave aufgeworfen.

Argumente


Wie kann man ohne Exceptions überhaupt vernünftig mit (variabel langen) Strings und Collections programmieren, überhaupt mit der ganzen STL in C++, bzw. mit Java allgemein?

Antwort: Problemlos. Ist der Fragesteller anderer Ansicht? Bitte Beispielprogramm liefern.


"Exception Specifications" ist nicht synonym mit "Exceptions"! Drei der zu Anfang genannten Artikel sprechen sich gegen Exception Specifications (in C++ oder Java) aus, nicht gegen Exceptions an sich.

Nichtsdestoweniger leisten auch sie dem Verdacht Vorschub, das Konzept "Exceptions" können irgendwie (vielleicht auch grundlegend) verkehrt sein.


"Cleaner, more elegant, and wrong", Raymond Chen, April 2004

Das Datenbankbeispiel vergißt, was Datenbanken ausmacht: Transaktionen, die mit Commitment oder Rollback abgeschlossen werden können. Genau dieses Idiom ist es, was Exceptionhandling so überlegen macht.

Diskussion

JoelSpolsky:

  1. They are invisible in the source code => even careful code inspection doesn't reveal potential bugs
  2. They create too many possible exit points for a function => create opportunities for surprise bugs caused by functions that terminated abruptly
Ja Spolsky beschreibt die Fakten korrekt. Bewertet sie aber anders als z. B. ich. Ich empfinde beide Fakten als positiv. Schließlich geht es hier nur darum, wie ich produktiver robusten Code schreibe. Mir helfen Exceptions den normalen Ablauf von dem anormalen zu trennen und so für mich verstädlicheren Code zu schreiben. Dafür zahle ich damit, dass ich damit rechnen muss, dass eine Methode in der Mitte beendet wird; mit finally oder Destruktoren in C++ komme ich damit ganz gut zurecht. Insgesamt also für mich ein gutes Geschäft. Spolsky hat aber Recht darin, dass, wenn man nicht auf die von ihm beschriebene Punkte achtet, kann man sich an den Exceptions wirklich "verletzen". Na ja, dass kann man mit diesen komischen virtuellen Methoden auch :-) -- GregorRayman

Die eine Fraktion bewertet Exceptions negativ, die andere (größere) positiv. Es können nicht beide recht haben. Entweder nützen Exceptions mehr, als sie schaden, oder sie schaden mehr, als sie nützen. "... produktiver robusten Code schreibe.": Es ist nicht im mindestens ausgemacht, dass exceptionbehafteter Code mehr oder weniger produktiv robust zu schreiben ist als exceptionsloser Code. "Mir helfen Exceptions den normalen Ablauf von dem anormalen zu trennen ...": Bereits das ist in meinem Augen ein Gedankenfehler, zu glauben, es gäbe zwei prinzipiell verschiedene Abläufe im Code. Nein, es gibt viele (sonst bräuchte man kein 'if' oder 'while') und sogenannte "Fehler" gehören dazu und sind nicht "anormal". "... zahle ich damit, dass ich damit rechnen muss, dass eine Methode in der Mitte beendet wird ...": Das ist aber nicht der entscheidende Preis, der gezahlt wird. Der Killer-Preis ist, dass beim reinen _Lesen_ von Codesequenzen 99 % der Entwickler die potenziellen Abläufe nicht mehr verstehen können. Ohne Vorhandensein von Exceptions ist die Codesequenz "a; b; c;" verständnismäßig klar wie der helle Tag, mit Vorhandensein von Eceptions ist es dunkel wie die Nacht. "... oder Destruktoren in C++ komme ich damit ganz gut zurecht.": Destruktoren sind unabhängig von Exceptions gut brauchbar, um z. B. beim frühzeitigen Verlassen von Funktionen ordentlich aufzuräumen; sie eignen sich also nicht als Argument für Exceptions. -- vgl

Bereits das ist in meinem Augen ein Gedankenfehler, zu glauben, es gäbe zwei prinzipiell verschiedene Abläufe im Code. Das habe ich auch nicht behauptet. Es gibt, aus der Sicht einer Prozedur, zwei Arten von Abläufen. Es gibt Abläufe im Code, die in der Domäne der Methode stehen, und es gibt Situationen, außerhalb dieser Domäne, die den Ablauf der Methode stören können. Z.B. in einer Prozedur, die eine Überweisung vornehmen soll kann es mehrere Abläufe geben, die davon abhängig sind, was sich auf den Konten befindet, wie viel überwiesen werden soll. usw. Entscheidungen die in der Domäne "Kontoführung" getroffen werden. Eine Störug aus der Domäne "Netzwerk" oder "Dateisystem" kann dazu führen, dass die "normalen" Abläufe nicht durchgeführt werden können. Ich finde es besser und verstädlicher, dieser Störungen an einer anderen Stellen zu behandeln, und so die logik der Domäne "Kontoführung" von den anderen zu trennen. Separation of concerns. Schließlich steht auch nicht in einem Rezept für Schokoladentorte, was der Koch machen muss, wenn der Strom abgeschaltet wird, oder wenn er einen Herzanfall kriegt.

Sicher, mann kann die Exceptions missbrauchen um die Abläufe zu verschleiern. Es ist aber Missbrauch und so kann man jedes Feature einer Programmiersprache missbrauchen. Man kann nicht die Exceptions desegen ablehnen, weil man sie missbrauchen kann. Sonst müsste man auch die virtuellen Methoden oder Objektvariablen auch ablehnen.

Übrigens, ich würde behaupten, dass es nicht stimmt dass 99% der Entwicker die Exceptions nicht verstehen. Und a; b; c; ist nicht klar wie der helle Tag - zumindest nicht, wenn man mit mehren Threads oder Interrupts arbeitet :-) -- GregorRayman

Der normale Ablauf eines Programs besteht im Auf- und Abbau eines Stacks. Eine Exception beschleunigt partiell den Abbau des Stacks und ist damit m. E. eher als nicht-lokaler Break denn als Goto zu sehen. Der durch ein Raise (bzw. Throw) induzierte 'Sprung' ist nicht beliebig sondern man springt nur innerhalb des aufrufenden Kontextes. Der Sprung unterstützt die Separation des Aspekts 'Fehlerbehandlung' indem der Sprung selbst nicht programmiert werden muss, sondern nur Start und Ziel.

In VisualWorks Smalltalk wird der Kontext bei Nichtbehandlung der Exception kopiert und steht als Smalltalkobjekt im Debugger zur Verfügung. Das ist das Standardprozedere bei Laufzeitfehlern und man gewöhnt sich dadurch enorm schnell an den Umgang mit dem Stack. Viele Smalltalker programmieren ausschließlich im Debugger und haben keinerlei Berührungsängste vor Exceptions. Das kann zu einem falschen Gefühl der Sicherheit führen, funktioniert aber im Allgemeinen gut. Durch Exceptions hervorgerufene Fehler sind in Smalltalk erheblich einfacher zu finden, als Fehler die durch Returncode-Missachtung entstehen.

In C++ profitiere ich bei der Entwicklung nicht in gleichem Maße von Exceptions. Ich muss mich auch mehr mit technischen Themen wie dem Speichermanagement herumschlagen. In C++-Büchern finden sich nicht ohne Grund diverse abschreckende Hinweise auf Schwierigkeiten. Wo sind also Gründe für den Einsatz? Dazu muss ich mich dem Thema Fehlerbehandlung auf abstrakterer Ebene nähern. Als Architekt oder Designer stelle ich mir folgende Fragen:

Kann ein Fehler ohne unangenehme Seiteneffekte lokal behandelt werden?

Welchen nicht-lokalen Umgang mit Fehlerzuständen kann ich mir im Kontext meiner eigenen Anwendung vorstellen? Konkret, welche Komponente muss auf Fehler welcher anderen Komponente reagieren?

Wie stelle ich sicher, dass die Modul-Schnittstelle nach aufgetretenen Fehlern unabhängig von der Fehlerbehandlung außerhalb des Moduls auf definierte Weise funktioniert.

Die Beantwortung kann den Einsatz von Exceptions nahelegen oder auf andere Lösungen hinweisen. Andere Lösungen können vielfältig sein: Fehlerpropagation über Eventmechanismen, Verwaltung von Erfolgs- und Statusinformationen, Behandlung in Form von Callbacks, Änderung der Architektur, etc... Ich bevorzuge Exceptions, weil sie explizit für diesen Zweck konzipiert wurden. Der Sprachdesigner ist sozusagen in Vorleistung getreten und bietet sie als Standardlösung an. -- SaschaDördelmann

Ganz nebenbei: Destruktoren sind unabhängig von Exceptions gut brauchbar, um z. B. beim frühzeitigen Verlassen von Funktionen ordentlich aufzuräumen; sie eignen sich also nicht als Argument für Exceptions. Konsequenterweise werden in der SpracheModula3 die Anweisungen RETURN und EXIT als Ausnahmen in Bezug auf PROCEDURE bzw. LOOP aufgefasst. Was ich damit sagen will: Auch C kennt schon spezielle Ausnahmen, nämlich 'return' und 'break', und ohne solche Ausnahmen bräuchte man keine Destruktoren, richtig? -- HenningThielemann

Exception-Kritikern wird von Exception-Befürwortern gerne untergeschoben, sie würden gegen die missbräuchliche Verwendung von Exceptions argumentieren. (Natürlich gleich mit dem Folgeschluss versehen, deswegen könne man Exceptions nicht ablehnen.) So auch hier von GR wieder geschehen. Nichts ist falscher. Wir argumentieren nicht gegen die missbräuchliche Verwendung von Exceptions, sondern gegen die gebräuchliche Verwendung von Exceptions. (Also bitte alles nochmal lesen, und diesmal richtig lesen.) -- vgl

Nur sind die Argumente gegen die gebräuchliche Verwendung von Exceptions nicht überzeugend. Was ist schon schlimm daran, wenn man weiß, dass das Programm aus der Mitte der Sequenz a; b; c; aussteigen kann? Inwiefern ist es für das Verstehen des Programmes besser, wenn jeder mögliche Verlauf explizit beschrieben werden muss?

Insofern, als es leicht zu verstehen ist, dass eine Sequenz "a(); b(); c();" auch unter Garantie als "a() dann b() dann c()" abgearbeitet wird, wohingegen es schwerst zu verstehen ist, dass eine Sequenz "a(); b(); c();" als entweder "teilweise a(), ohne b(), ohne c()" oder "a() dann teilweise b(), ohne c()" oder "a() dann b() dann teilweise c()" oder "a() dann b() dann c()" abgearbeitet wird. Und zwar muss letzterer Gedankengang beim Erblicken der Codesequenz "a(); b(); c();" verständismäßig selbst dann geleistet werden, wenn weder a(), noch b(), noch c() faktisch überhaupt Exceptions werfen. -- vgl

[Nachtrag 2008] Zitat aus dem oben genanntem Google C++ Style Guide: "Pros: [...] Cons: [...] More generally, exceptions make the control flow of programs difficult to evaluate by looking at code: functions may return in places you don't expect. This results maintainability and debugging difficulties. You can minimize this cost via some rules on how and where exceptions can be used, but at the cost of more that a developer needs to know and understand. [...]" -- vgl

Das von SD angebrachte Argument der vermeintlichen Returncode-Missachtung akzeptiere ich nicht. Wenn ich eine Funktion programmiere, die eine wichtige Informationen an den Aufrufer zurückzugeben hat, dann gebe ich an den Aufrufer eben ein solches Objekt zurück. Wenn ich zudem sichergehen will, dass der Aufrufer diese Information unmöglich versehentlich ignorieren kann, dann spendiere ich diesem Objekt eine Kennung, die, sollte sie bei Destruktion des Objekts noch gesetzt sein, das Programm unmittelbar beendet. Der Aufrufer muss also mit dem Objekt hantieren, so dass die Kennung verschwindet. -- vgl

Das macht die Fehlersuche nicht unbedingt leichter. Es knallt zwar, aber der Zeitpunkt hängt von der Dekonstruktion und nicht von der Fehlererkennung ab. (Ganz nebenbei gibt es in Smalltalk gar keine Dekonstruktion, wie du sie von C++ gewohnt bist.) -- SD

(a) Mir ging es darum, das Argument der vermeintlichen Returncode-Missachtung zu entkräften. (b) Bei Exceptions hängt der Zeitpunkt ebenfalls nicht von der Fehlererkennung ab. -- vgl

Zu (b): Wovon denn, deiner Meinung nach? -- SD

Ich hatte deinen Hinweis auf den Zeitpunkt so verstanden, dass sich die ignorierte Ausnahmesituation erst zum Zeitpunkt der Dekonstruktion des Ausnahmeobjektes zu erkennen gibt, und nicht bereits zum Zeitpunkt der Ausnahmefeststellung. Das ist richtig, die Ausnahmefeststellung hat in dem Moment stattgefunden, als das Ausnahmeobjekt erzeugt wurde (bzw. genaugenommen - wahrscheinlich - unmittelbar davor). Nun, bei Exceptions gibt sich die ignorierte Ausnahmesituation ebenfalls nicht zum Zeitpunkt der Ausnahmefeststellung zu erkennen, also wenn (unmittelbar danach) die Exception erzeugt und geworfen wird, sondern erst dann, wenn die Exception nicht gefangen wird. (Wobei übrigens, meine Erfahrung aus Java-Projekten, gerne irgendwelche obskuren äußeren catch-Blöcke, zudem gerne noch gefährlicherweise auf java.lang.Throwable statt auf java.lang.Exception greifend, diese doch noch wegfangen, und also doch ignoriert werden.) -- vgl

Die normale Abarbeitung wird exakt zum Zeitpunkt der Fehlererkennung mit einem Sprung in den aufrufenden Kontext durchbrochen. Was passiert also zwischen 'werfen' und 'nicht fangen'? In C++ mögen hier eine Menge Destruktoren durchlaufen werden, in Smalltalk gibt es mit 'ensure:' ebenfalls Aufräum-Mechanismen. Aber im Grunde sind die Effekte unmittelbar und nicht systematisch verzögert. Wer Exceptions fängt und weiterwirft, verzichtet auf diesen Vorteil, da gebe ich dir völlig Recht. --SDö

Die Abarbeitung wird _nicht_ (und schon gar nicht exakt) zum Zeitpunkt der Fehlererkennung durchbrochen, da erst der Fehler erkannt wird und (beliebig lange) _danach_ die Exception geworfen wird. Folgend ein Beispiel aus dem Java SDK, wo dies zu sehen ist. Übrigens auch ein schönes Beispiel, das zeigt, dass die durch Exceptions mitgeteilten Daten meist nur schwammig über die Fehlerursachen informieren (hier bspw. ist auf programmiertechnisch brauchbare Weise nicht unterscheidbar, ob der Index zu klein oder zu groß war). -- vgl

public class ArrayList [...] {
    [...]
    public Object get(int index) {
        RangeCheck(index);
        return elementData[index];
    }
    [...]
    private void RangeCheck(int index) {
        if (index >= size || index < 0) // <- Fehlererkennung (potenziell)
            throw new IndexOutOfBoundsException( // <- Unterbr. Abarbeitung
                    "Index: "+index+", Size: "+size);
    }
    [...]
}

Dass heißt, du kritisierst eine bestimmte Art der Verwendung und nicht den Mechanismus an sich? Natürlich kann ich verzögert oder gar völlig unmotiviert eine wenig aussagekräftige Exception schmeißen, aber das würde ich in die Kategorie Missbrauch einsortieren. Andernfalls wäre zu belegen, dass es anders besser geht, quasi ohne die Freiheit, Unfug zu programmieren. -- SDö

Doch, ich kritisiere den Mechanismus an sich, und zwar mit den am Beginn dieses Abschnitts von Spolsky zitierten Argumenten, denen ich mich vollinhaltlich anschließe (und die ich anhand der Beispielsequenz "a(); b(); c();" in eigenen Worten auszudrücken versucht habe). Das Übrige sind Nebenkriegsschauplätze. (Die letzten Anmerkungen ergaben sich nur daraus, dass ich den Eindruck hatte, du würdest behaupten, Exceptions würden zum Zeitpunkt der Fehlererkennung ausgelöst werden, was ja nicht stimmt, da Exceptions erst nach Fehlererkennung ausgelöst werden. Deine Aussage "Die normale Abarbeitung wird exakt zum Zeitpunkt der Fehlererkennung [...] durchbrochen." hörte sich für mich jedenfalls so an. Aber wie gesagt, Nebenkriegsschauplatz.) -- vgl


Ich habe fast immer gute Erfahrungen mit der Verwendung von Exceptions gemacht. Wobei die Möglichkeiten in Abhängigkeit von der verwendeten Programmiersprache dramatisch variieren. Es ist wohl unbestritten, dass Exceptions ein leicht zu missbrauchendes Programmiermittel sind. Fehlt im Team eine Person mit Erfahrung im Umgang mit Exceptions, sollte man überlegen, ob man nicht besser die Finger von ihnen lässt. Aber ein solcher Rat ist natürlich auf nahezu alle Bereiche der Programmierung anwendbar ;-)

-- SaschaDördelmann

Ich habe mit Exceptions nur mit Zusammenhang mit altem (C++) Code unangenehme Erfahrungen gemacht. Wenn eine Prozedur, die Exceptions wirft, von einer alten, die damit nicht rechnet, dass sie in der Mitte beendet wird, und deswegen nicht aufräumt, aufgerufen wird, bleibt das Programm in einem unangenehmen Zustand. -- GregorRayman


Warum gehen eigentlich 90% der "Exception Diskussionen" an sauberem RAII vorbei? "Wenn eine Prozedur in der Mitte beendet wird, und nicht aufräumt" ist das in C++ schon mal falsch. Einfach alles aufzuräumende in einen Destruktor und in einen Block auf den Stack. Dann kümmert sich die Sprache um's aufräumen. Das das in Java nicht geht, sehe ich persönlich als einen der Java-Sprach-Bugs oder Übervereinfachungen. finally{} ist ein schlechter Workaround, der nicht skaliert. Die Regel zum Aufräumen ist doch ganz einfach: immer, egal wie beendet. Macht UNIX mit Prozessen auch so. Wer da jetzt mit catch(...) kommt, liegt meiner Meinung nach auch wieder meistens falsch, weil er einen Destruktor nehmen sollte. Da kann man auch schnell kleine Klassen machen, die z.B. member-Werte speichern und im Destruktor rückgängig machen.

Auch sind Exceptions keine Alternative zu Rückgabewerten. Wenn man was zurückgibt, nimmt man einen Rückgabewert. Kein Grund, um über Exceptions zu meckern, die können doch nichts dafür, wenn sie vergewaltigt werden. Exceptions sind aber gut für Abbrüche. Wenn ein subsystem kaputt ist, kann es eine Applikationsinstanz (Instanz! Keine Prozedur, sondern eine Instanz!) killen und ein Framework kann das abfangen und beispielsweise Notfallmassnahmen ergreifen. Das kann man sogar schachteln.

In Java geht das alles nicht so wirklich. Da gibt es z.B. code, der IndexOutOfBounds? exceptions abfängt. Das liegt aber nicht an der IndexOutOfBoundsException? und auch ausnahmsweise mal nicht an Java sondern schlicht am Entwickler. Man kann auch ohne gotos schlechten Code schreiben. Disziplin muss vom Programmierer kommen, nicht von der Sprache, die kann das nämlich sowieso nicht richtig (wobei ich mich frage, warum Java neuer und schlechter als C++ ist, vielleicht, weil zu viele an "C++ in 24 Stunden" geglaubt haben?).

Für GUIs mag so ein "wenn es zu 90% funktioniert, reicht das" Ansatz ja reichen, aber da kann man vielleicht auch Scriptsprachen mit "eval" benutzen. Für Sachen, die einfach funktionieren müssen, mag ein Abbruch mit analysierbaren Informationen viel besser sein, als ein schlecht behandelter Fehler. Exceptions kann man z.B. je Ebene Informationen hinzufügen (in dem man in catch(Informative &e) { e << "extra info" } hinzufügt). Damit kann man dann theoretisch auch sinnvolle Fehlermeldungen erzeugen (die beispielsweise sagen, was beim Dateiöffnen schiefging, bei welcher Datei, wofür die gebraucht wird bzw. warum sie benutzt wird, wo sie konfiguriert wurde und das am Ende auch noch in der richtigen Sprache - das wird in C schwierig, weil man das schlecht in einen int kodiert bekommt :-)).

Meiner Meinung nach ist also die Verwendung von Exceptions nicht falsch. Die Verwendung von catch(...) ist aber oft (meistens?) falsch. In Java kann man Destruktoren leider nicht trauen, damit funktioniert das ganze Paradigma nicht richtig; und finally{} skaliert nicht, ist daher nur ein schlechter Ersatz. In C++ aber passen Exceptions, Aggregate und const prima zusammen und ermöglichen es, bei Bedarf eher deskriptiv als prozedural zu arbeiten (ein Pradigma, dass man mit Java nicht brauchbar emulieren kann). So ein deskriptiver Programteil funktioniert dann oft sehr gut mit Exceptions: entweder gibt es einen totalen Abbruch (d.h. kein Ergebnis) oder ein richtiges Ergebnis.

so jetzt zerreißt mich :-) SteffenDettmer <steffen@dett.de>

(ab hier Altlasten. Wer sich traut, soll es refaktorieren.)

Hallo, Udo. Ich sehe, du hast dich viel mit dem Thema beschäftigt. Du vertritts deine Ahnungen sehr glaubwürdig. Ich denke, "Exceptions" sind für dich der richtige Weg. Viel Spaß damit. -- VolkerGlave

Sorry, ich empfinde das meiste von dir Gesagte als wirres Zeug. Du sprichst andauernd von irgendwelchen "Fehlern". "Fehler" sind ein zu "Exceptions" vollkommen paralleles Thema. Wären "Exceptions" für "Fehler" erfunden worden, hätten sie "Errors" geheißen. Da "Exceptions" mit "Fehlern" nicht direkt zusammenhängen, ist es also auch Blödsinn, in C als Exception-Parallele Fehlercodes zu behaupten. Sondern es ist so: In C gibt es keine Exceptions, also muss ich die Information, die ich meinem Aufrufer mitzuteilen müssen glaube, in z. B. einer Struktur (und eher nicht in einer globalen Variable oder einem "Integer"-Wert) zurückgeben (als z. B. Rückgabewert oder z. B. einem Ausgabeparameter oder z. B. einer Bei-Bedarf-Abfrage-Methode). Natürlich und glücklicherweise kann man das in C++ und Java ebenfalls tun. -- VolkerGlave

Nebelkerzenwerfen ist wohl ein Hobby von dir. (a) Ja, Chen hat möglicherweise ein schlechtes Buch erwischt (keine Ahnung), aber das ist eben sein Aufhänger, zu zeigen, dass es "mit Exceptions" schwerer fällt als "ohne Exceptions", codemäßig zu erkennen und auszudrücken, welche besonderen Situationen eintreten können, und wie (und ob) reagiert werden möchte oder muss. (b) Das Datenbankbeispiel vergißt nicht unbedingt, was Datenbanken ausmacht, da ein signifikanter Anteil heute üblicher Datenbanken keineswegs die in dem Beispiel stehenden Operationen (SQL: DDL-Befehle) in einer Transaktion zu klammern in der Lage sind. (c) Das eigentlich von Chen diskutierte Beispiel ist nicht das Datenbankbeispiel (das ist nur der Aufhänger), sondern das darauf folgende Beispiel. -- VolkerGlave

Ich bin mir nicht sicher, ob diese Artikel (von 1999 und 2001) als Argument dafür oder dagegen stehen, "Exceptions" für ein geglücktes Sprachkonstrukt zu halten. Sutters Kommentar in #61 [1999]: "[...]. After years of differing with Dave Abrahams on this point, I can now in good conscience come around to his point of view that "exceptions are not magical" -- they are simply another failure case, albeit with complex programming semantics in C++ that come into play when you actually use them, but conceptually no different from an error return code." (Hervorhebung von mir) deutet darauf hin, dass "Exceptions" nur mit erheblicher Mühe in ihrem Wirken zu durchschauen sind. Und das ist ja die/meine Kritik. -- VolkerGlave

Doch, für gefährlich halte ich sie (jedenfalls bislang noch), und zwar nicht, weil sie "schwer verständlich" wären (dagegen hätte ich nicht viel), sondern weil sie m. M. n. zu schwer verständlich sind, so schwer, dass ihre versuchte Verwendung meistens mehr Schaden anrichtet als Gutes tut. Dagegen hülfe, sie im Sprachschatz gar nicht erst anzubieten (so, wie Java endlich mit dem Sprachmittel "goto" aufgeräumt hat [bei Exceptions wussten sie's nicht besser, das war gerade in Mode gekommen ...]). -/- Die Debatte braucht nicht sortiert zu werden, sie passt hier (ja unter der Überschrift "Diskussion") gut hin. -- VolkerGlave


KategorieArtikel KategorieException
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern
Text dieser Seite ändern (zuletzt geändert: 15. Juni 2013 3:18 (diff))
Suchbegriff: gesucht wird
im Titel
im Text