Votrag zum Thema: Exceptions in C++ - Gliederung

[exbs]

Hi,

ich habe dieses Semester einen Vortrag über Exceptions in C++ gehalten und jetzt noch an, eine Ausarbeitung zu schreiben. Als Gliederung habe ich mir folgendes aufgeteilt:

PDF auf Rapidshare

Wenn es Probleme bei Download gibt, dann stelle ich es nochmal als Klartext ein.

So was haltet ihr davon ? Zu sehr ins Detail ? Zu Oberflächlich ? Die Arbeit soll insgesamt so ca. 12 Seiten haben.


MfG

[Xin]

Was soll der Vortrag bringen? Möchtest Du Deinem Prof zeigen, wie toll Exceptions sind? Geht es darum die kurzfristigen Vorteile zu beleuchten, oder geht es darum, das Chaos anzusprechen, dass Exceptions in großen Projekten verursachen?

Ich stehe dem Konzept "Exceptions" extrem kritisch gegenüber, weil ich es auch schon mehrfach erlebt habe, wie dieses Konzept der Fehlerbehebung zu einem Konzept des Fehlerversteckens wurde.
Ich berichte Dir gerne aus zweiter Hand, wie Exceptions in der realen Entwicklung durch Catch-Alls geschlunzt werden, weil für die sehr aufwendige und informationszerstörende Fehlerbehandlung durch Exceptions in der realen Welt oftmals die Zeit fehlt.
Aus zweiter Hand, weil ich das Zeug debuggen durfte - ich habe es nicht geschrieben.
Berichte doch auch darüber, dass Exceptions gerne vererbt werden, was zu kuriosem Verhalten der Software führen kann.
Das findet seinen bisherigen Höhepunkt im Exception-Ping-Pong, wo Exceptions falsch behandelt werden, aber eben behandelt werden, was dazu führt, dass der Fehler im Programm für behoben erklärt ist, während Zombie-Objekte die nächsten Exceptions werfen, die nichts mit dem eigentlichen Fehler zu tun hat.

Und dann erkläre ich als Diplom-Informatiker, der vor 25 Jahren begonnen hat zu programmieren, dass die Frage, wie Programmierfehler ohne dieses Konzept behandelt wurden, die ersten Antworten liefern auf die Frage, wie Programmierfehler ohne dieses Konzept in Zukunft behandelt werden.
Exceptions sind gerade in Code teuer, der performant laufen soll - wenn keine Exception geworfen wird und besonders wenn Exceptions geworfen werden. Auch das gibt es heute noch, dass Code performant laufen muss - denn egal, wie schnell Computer heute auch sind und Computer sind heute echt scheiße schnell, echte Probleme lassen sich wesentlich besser mit performanten Algorithmen als mit schnelleren CPUs lösen.

In meinem gesamten privaten Code werfe ich keine einzige Exception. Ich bin sicher, dass ich nicht alle Fehler behandle. Mein privater Code hat Bugs.
Aber aus meinem Berufserfahrung heraus sage ich Dir, dass ich Code, der mit Exception arbeite nichtmals hab so sehr vertraue, wie meinem Code. Und ich garantiere dafür, dass mein Code sauberer und performanter läuft als jeder Exception-Code, der nicht zu "Lehrzwecken" dem Idealbild nach entwickelt wurde.
Jeder Code, der nach althergebrachter Weise Fehler behandelt, zerstört keine Informationen, ist performanter, aber nach derzeit herrschender Lehrmeinung schlechter wartbar. Meiner praktischen Erfahrung nach, ist er deutlich besser wartbar.
Darum rate ich nur in absoluten Ausnahmefällen zu Exceptions, denn das Konzept ist gut. Es wird aber so gut wie nie in Ausnahmefällen verwendet.

Mein Fazit: Wer nicht hochprofessionell programmiert und genau versteht, was Exceptions in ausreichend großen Projekten anrichten können, sollte von Exceptions die Finger lassen. Für alle anderen sollte es einen Exception-Beauftragten geben, der Exceptions verwaltet und vom kompletten Projekt alle Exceptions persönlich mit Namen kennt und versteht, was es bedeutet, wenn von welcher Exception abgeleitet wird oder die Konsequenzen versteht, wenn jene Exception dort geworfen wird.
Alles andere landet im Chaos.
Exceptionbeauftragte habe ich noch nie gesehen. Hochprofessionelle sind selten. Exceptionchaos sah ich überall, wo einem Exceptions um die Ohren flogen.

[exbs]

Danke dafür, dass du deine Erfahrung so ausführlich mit mir teilst.

Der Sinn und Zweck dieses Vortrages erschließt sich mir auch nicht ganz, aber im Bachelor-System ist es eben Pflicht ein paar Seminare zu belegen. Im Grunde geht es darum, dass die allgemeinen Sprachkonzepte vermittelt werden. Da die Exceptions zu C++ gehören, müssen sie auch erwähnt werden und den Leuten muss gesagt werden was sie machen. Die Frage ist, ob es gut ist, wenn ein Einäugiger den Blinden etwas beibringen muss. Was ich damit meine ist, dass ich selber wenig Erfahrung in der C++ Programmierung habe und langsam mit wachsenden Aufgaben auch die Frage nach neuen Konzepten kommen (bzw. es wächst natürlich das Interesse). Wenn du bereits deine negativen Erfahrungen gemacht hast, dann hattest du schon deinen Lernprozess. Ich muss auch gestehen, dass ich vor diesem Seminar keine besondere Bedeutung auf Exceptions gelegt habe. Bisher habe ich es eben anders gelöst. Und es hat funktioniert. (meistens ) Aber wenn man sich dann mit dem Thema beschäftigt sind die einschlägigen Quellen (Bücher, Wikipedia, Internet im Allgemeinen ... ) nur Quellen für die theoretischen Ansätze und "überragenden" Vorteile von Exceptions im Vergleich zu anderen Techniken. Nirgends (nicht wahr, wenn man sucht dann findet man sicher auch deine Position im Netz), wird allerdings auf die praktische Sicht der Dinge hingewiesen. Aus diesem Grund finde ich es immer sehr schön, wenn praxisnahe User davon berichten. Unser Prof. hatte dazu nichts gesagt. Aber das ist das allgemeine Uni Problem. Fern ab der Realität und alles und allem fliegen die Engel aus dem Hintern.

Gut aber zurück zur Sache. So interessant ich deinen Standpunkt finde, auch wenn ich natürlich mit meiner begrenzten Erfahrung nur abnicken kann, wird mir nichts anderes übrig bleiben, als die gestellte Aufgabe zu erfüllen. Da ich selber nicht genau genug darlegen kann, was du geschrieben hast und ich nur ungern eine Ausarbeitung bestehend aus einem Zitat schreiben will, bleibt die ursprüngliche Frage, ob man die Gliederung durchgehen lassen kann, wenn man davon ausgeht, dass es sich um eine eher theoretische Betrachtung handelt ?

Solltest du noch Artikel haben, die deinen Standpunkt untermauern, oder mir sagen kannst wie ich eine recht einfache Situation beschreiben kann, dann werde ich einen kritischen Abschnitt meiner Ausarbeitung hinzufügen. Aber um das machen zu können, muss ich eben wissen, was ich schreibe.

MfG

[Xin]

Bis wann brauchst Du das?

Diese Woche schaffe ich das nicht mehr.

[exbs]

Es hat noch Zeit. Ca. 5 Wochen.

[fat-lobyte]

Was soll der Vortrag bringen? Möchtest Du Deinem Prof zeigen, wie toll Exceptions sind? Geht es darum die kurzfristigen Vorteile zu beleuchten, oder geht es darum, das Chaos anzusprechen, dass Exceptions in großen Projekten verursachen?

Ich stehe dem Konzept "Exceptions" extrem kritisch gegenüber

Das ist bekannt Dennoch wäre es fair, wenn du deine Meinung als solche deklarierst und somit auch andere zulässt.

Exceptions sind gerade in Code teuer, der performant laufen soll - wenn keine Exception geworfen wird und besonders wenn Exceptions geworfen werden. Auch das gibt es heute noch, dass Code performant laufen muss - denn egal, wie schnell Computer heute auch sind und Computer sind heute echt scheiße schnell, echte Probleme lassen sich wesentlich besser mit performanten Algorithmen als mit schnelleren CPUs lösen.

Das ist wahrscheinlich wahr. Diesen Luxus leiste ich mir allerdings häufig. Es gibt nämlich die möglichkeit zu differenzieren: Real sind CPU Zyklen tatsächlich billig, wenn ich code nur 1,2,3 mal aufrufe, dann brauche ich nicht aufs äußerste zu optimieren. In der 3. inneren Schleife in einem Algorithmus der gigantische Daten verarbeitet - wie soll ich sagen - selber Schuld wer da zu exceptions greift.

In meinem gesamten privaten Code werfe ich keine einzige Exception. Ich bin sicher, dass ich nicht alle Fehler behandle. Mein privater Code hat Bugs.
Aber aus meinem Berufserfahrung heraus sage ich Dir, dass ich Code, der mit Exception arbeite nichtmals hab so sehr vertraue, wie meinem Code.

Das ist schön, aber deine persönliche Meinung. Kein Argument gegen Exceptions.

Und ich garantiere dafür, dass mein Code sauberer und performanter läuft als jeder Exception-Code, der nicht zu "Lehrzwecken" dem Idealbild nach entwickelt wurde.

Nehmen wir mal an das stimmt: wer weiß wie der Code mit Exceptions ausshen würde? Vielleicht liegt das nämlich nur daran dass du gut programmieren kannst, nicht daran dass Exceptions von Grunde auf falsch sind.

Mein Fazit: Wer nicht hochprofessionell programmiert und genau versteht, was Exceptions in ausreichend großen Projekten anrichten können, sollte von Exceptions die Finger lassen. Für alle anderen sollte es einen Exception-Beauftragten geben, der Exceptions verwaltet und vom kompletten Projekt alle Exceptions persönlich mit Namen kennt und versteht, was es bedeutet, wenn von welcher Exception abgeleitet wird oder die Konsequenzen versteht, wenn jene Exception dort geworfen wird.
Alles andere landet im Chaos.
Exceptionbeauftragte habe ich noch nie gesehen. Hochprofessionelle sind selten. Exceptionchaos sah ich überall, wo einem Exceptions um die Ohren flogen.

So wie ich das sehe hast du in deinem Leben schon zuviel schlechten Code gesehen. Das ist bedauerlich, und ich kann durchaus deine Frustration mit Exceptions verstehen.
Aber deine Argumentation sieht für mich so aus: "Man kann viel falsch machen, deswegen sollte mans gleich lassen.".
Wer jemals einen Iterator mit dem falschen Concept in einen STL-Algorithmus gesteckt hat, wird warhscheinlich abgeschreckt werden, so furchtbar sind die Fehlermeldungen. Macht mans allerdings richtig steht einem ein unglaublich mächtiges Werkzeug zur verfügung.

Ich finde anstatt Exceptions zu verteufeln solltest du darauf hinweisen wie man sie richtig verwendet. Es gibt nämlich eben ein paar Dinge die man beachten muss:

1) Keine Exceptions in Destruktoren.
2) catch(...) ist verboten.
3) catch(const std::runtime_exception&) ist verboten.
4) Exceptions sind Sparsam einzusetzen, und zwar nur in Ausnahmefällen, wie der Name schon sagt.
5) Wenn man mit der Exception nichts anzufangen weiß, dann fängt man sie auch nicht auf.
6) Nur ein Exception-Typ für einen Fehler. Diagnostikinformationen einbauen!
7) ... (Bitte weitere Punkte anführen)

Hält man sich an Regeln (und an Common sense) können sie durchaus nützlich sein.

- Ich möchte nämlich, wenn ich ein Objekt anlege, dass dieses Objekt nach vollendetem Konstruktoraufruf gültig ist. Ich brauche keine "Hängenden" Objekte die ich erst noch mit object.isValid() und object.getErrorCode(), object.getErrorMessage() bearbeiten.
- Ich möchtet nicht bei jeder operation bei der Fehler auftreten den Fehler abfangen, verarbeiten und weiterreichen. Oft sind die Fehlerquellen die gleichen, und dann will ich nicht jedes mal das gleiche abfragen:
- Meine Ressourcen sind mit Exceptions gleich sicher. Packe ich alle Ressourcen in den Destruktor kann nichts passieren.

Eine Exception heißt für mich: Achtung! Da ist was gewaltig faul. Zustand wiederherstellen oder Programm beenden. Knallt eine Exception durch, weiß ich dass dort ein Fehler ist. Eine halbe Stunde später einen ungültigen Zeiger zu referenzieren, der "hoffentlich" NULL ist ist weniger hilfreich.

Ich benutze in meinem Code exceptions. Ich bin weder Stolz darauf, noch schäme ich mich. Sie gehören zur Sprache und haben wie jedes andere Element ihre Tücken. Ich empfinde es als ziemlich Sinnfrei darüber zu schimpfen und sie zu Verteufeln.

Außerdem finde ich ja virtuelle Methoden genauso Schlimm. Man weiß ja nie welche aufgerufen wird. Und Mehrfachvererbung sowieso, ich meine da blickt ja keiner mehr durch. Oder Templates, das muss ja ein riesiger Overhead sein damit das generisch Funktioniert und die Fehlermeldungen sind unlesbar. Und überhaupt, Operatorüberladung ist ja das schlimmste, da kann man ja den Datentyp nicht erkennen. Und die IOStreams, die std::string's, die std::vector<>s, die Algorithmen, alles Hexenwerk. Verbrennen sollte man es.

[Xin]

Ich stehe dem Konzept "Exceptions" extrem kritisch gegenüber

Das ist bekannt Dennoch wäre es fair, wenn du deine Meinung als solche deklarierst und somit auch andere zulässt.

Habe ich das nicht, wenn ich schreibe: „ICH stehe dem Konzept Exceptions extrem skeptisch gegenüber“ oder gibt es eine hier Zensur, wenn Du oder Kerli sich zu Exceptions äußern?

Ich finde, das ist fair genug.

In der 3. inneren Schleife in einem Algorithmus der gigantische Daten verarbeitet - wie soll ich sagen - selber Schuld wer da zu exceptions greift.

Nicht nur throw kostet Zeit - auch try kostet, auch wenn es so unschuldig aussieht und eigentlich ja auch nichts tut, um den Algorithmus weiter zu bringen.

Und in einer Umgebung, die Exceptions als Normal akzeptiert, ist es nicht unwahrscheinlich, dass die 3. innere Schleife eine Funktion wirft, die try verwendet.

Und ich garantiere dafür, dass mein Code sauberer und performanter läuft als jeder Exception-Code, der nicht zu "Lehrzwecken" dem Idealbild nach entwickelt wurde.

Nehmen wir mal an das stimmt: wer weiß wie der Code mit Exceptions ausshen würde? Vielleicht liegt das nämlich nur daran dass du gut programmieren kannst, nicht daran dass Exceptions von Grunde auf falsch sind.

Wem hilft es, wenn ich gut mit oder ohne Exceptions programmieren kann und andere mit oder ohne Exceptions schlecht programmieren?

Wer mit Exceptions Mist baut, verkompliziert die Angelegenheit meist massiv, weil ein Programm mit einer gefangene Exception weiterläuft, aber invalide Objekte hinterlässt. Wenn es dann kracht, ist oftmals nicht mehr sinnvoll nachzuvollziehen, wie das invalide Objekte entstanden ist.

So wie ich das sehe hast du in deinem Leben schon zuviel schlechten Code gesehen. Das ist bedauerlich, und ich kann durchaus deine Frustration mit Exceptions verstehen.
Aber deine Argumentation sieht für mich so aus: "Man kann viel falsch machen, deswegen sollte mans gleich lassen.“.

Nein - im Gegenteil - ich finde Exceptions sogar gut - Wenn man sie in Ausnahmen benutzt. Die einzige für mich wirklich grundsätzlich legitimierte Ausnahme ist ein try...catch in main. Alles andere ist eigentlich ein Regelfall.

Ich finde anstatt Exceptions zu verteufeln solltest du darauf hinweisen wie man sie richtig verwendet. Es gibt nämlich eben ein paar Dinge die man beachten muss:

1) Keine Exceptions in Destruktoren.
2) catch(...) ist verboten.
3) catch(const std::runtime_exception&) ist verboten.
4) Exceptions sind Sparsam einzusetzen, und zwar nur in Ausnahmefällen, wie der Name schon sagt.

Alleine diese Regeln werden regelmäßig verletzt - besonders catch(...) ist während der Entwicklung sehr verlockend, und wenn’s funktioniert, dann funktioniert es ja. Und dann bleibt das catch(...) stehen oder wird vergessen.

Das passiert auch professionellen Entwicklern, denn da wo ich das hassen gelernt habe, wurde durchaus vergleichsweise sehr professionell gearbeitet. Und das meine positiv. Trotzdem ist Zeitdruck in der Realität nach dem Studium sehr präsent und in einem Entwicklungsteam reicht eine Person, die eben eine andere Meinung teilt und der das dann anders macht. Und die ist Regelfall mehrfach vorhanden.
Aus genau dem Grund bin ich von dem Konzept nicht überzeugt.
Gravierende Fehler können durch einen einzelnen verschleppt werden, damit fehlt die Zuständigkeit. Es entsteht eine "Verkettung unglücklicher Umstände". Diese unglücklichen Umstände folgen allerdings einer Regel, die durch den Gebrauch von Exceptions vorgegeben wird.
Und das ist der Punkt, an dem das Konzept "Exceptions" hakt. Der Verlauf der Verwendung führt immer wieder zu einem ganz spezifischen, das Produkt im höchsten Maße gefährdenden Design-Fehler.

5) Wenn man mit der Exception nichts anzufangen weiß, dann fängt man sie auch nicht auf.

Was man nicht bestimmen kann, weil eine Ableitung einer Exceptions, die man fängt, sich eben auch hier verfängt und behandelt wird - wie auch immer.

Werden Exceptions nicht gefangen, steigt das Programm aus. Dann hätte man es auch gleich explodieren lassen. Die Meldung "Eine Exception ist aufgetreten, alle Daten sind verloren" mit "Okay" zu quittieren macht mich nicht glücklicher, denn es ist eben nicht "Okay".
Und schonmal gar nicht will ich dem Arsch von Programmierer meine Absolution mit "Okay" erteilen, der soeben meine Arbeit vernichtet hat, weil er scheiße Programmiert hat. Ich will dem Typen den Hals umdrehen, okay?

6) Nur ein Exception-Typ für einen Fehler. Diagnostikinformationen einbauen!

Algorithmen machen keine Fehler. Fehlende Dateien muss man berücksichtigen. Ich sehe keinen Grund, Exceptions zu werfen. Ausnahmen sind unbehandelte Code-Pfade, die ich der aufrufenden Funktion auf's Auge drücke.

Wenn der Fehler "Division durch Null" vorbeifliegt, dann weiß der Catch-Block nicht, wer diesen Fehler geworfen hat. Er fliegt halt hier vorbei. Diese Information ist verloren. Wie soll der Catch-Block reagieren? Insbesondere, wenn diese Exception von einem Programmteil geworfen wird, der nach dem Catch-Block implementiert wurde, der Catch-Block also diese Möglichkeit gar nicht berücksichtigen kann.

Der Catch-Block wird sich drum kümmern - aber niemand kann sagen, ob danach ein valides oder invalides Objekt zurückbleibt.

7) ... (Bitte weitere Punkte anführen)

Benutze keine Exceptions, dann kannst Du die zuvor genannten Regeln vergessen. Je weniger Regeln Du beachten musst, desto weniger Regeln kannst Du verletzen.

- Ich möchte nämlich, wenn ich ein Objekt anlege, dass dieses Objekt nach vollendetem Konstruktoraufruf gültig ist. Ich brauche keine "Hängenden" Objekte die ich erst noch mit object.isValid() und object.getErrorCode(), object.getErrorMessage() bearbeiten.

Ich auch nicht. Deswegen ist mir die C++-Semantik von new auch zuwider und wird in Genesys so nicht eingesetzt. Dort bekommst Du vielleicht ein Objekt, bevor Du es nutzen darfst, musst Du den Codepfad in zwei Möglichkeiten teilen: Du hast ein valides Objekt - oder Du hast kein Objekt.

- Ich möchtet nicht bei jeder operation bei der Fehler auftreten den Fehler abfangen, verarbeiten und weiterreichen. Oft sind die Fehlerquellen die gleichen, und dann will ich nicht jedes mal das gleiche abfragen:

Die Fehlerquelle mag die gleiche sein, aber vielleicht an anderer Stelle im Code.
Datei nicht gefunden... okay, kann behoben werden.
Der Fehler kann an x-Stellen auftreten. Zwischen diesen Stellen können bereits Handlungen Objekte verändert haben und in einem invaliden Übergangsstatus hinterlassen haben. Muss man sich jetzt um diese Zombies kümmern oder nicht?
Wie oft können im Code Dateien nicht gefunden werden und wird dieser Fehler behandlet? Wie oft kann die Exception geworfen werden. Das ergibt eine Multiplikation. Im Worst-Cast musst Du pro Catch alle throws dieser Exception gesondert bearbeiten. Die Idee Code zu sparen ist löblich, faktisch trennt man den Fehler vom Algorithmus, muss aber bei der Fehlerbehandlung aber an vollkommen anderer Stelle erst wieder herausfinden, wie man auf die fehlerhafte Stelle reagieren muss. Dass kann auch alles in der Exception beschrieben stehen, wie Du es Deiner 6. Regel beschrieben hast. Aber wenn ich da alle Informationen zusammentrage, wie ich den Fehler behebe - wieso behebe ich nicht einfach den Fehler, sondern lasse das jeweils die Funktionen machen, die mich gerufen haben - und das können ja beliebig viele sein? Spart das Code?

Eine Exception heißt für mich: Achtung! Da ist was gewaltig faul. Zustand wiederherstellen oder Programm beenden. Knallt eine Exception durch, weiß ich dass dort ein Fehler ist. Eine halbe Stunde später einen ungültigen Zeiger zu referenzieren, der "hoffentlich" NULL ist ist weniger hilfreich.

Exceptions werden zu häufig als Regelfall benutzt oder während der Entwicklung übergangen, denn wenn der Algorithmus fertig ist, dann wird die Exception ja nicht
mehr auftreten.

Außerdem finde ich ja virtuelle Methoden genauso Schlimm. Man weiß ja nie welche aufgerufen wird. Und Mehrfachvererbung sowieso, ich meine da blickt ja keiner mehr durch. Oder Templates, das muss ja ein riesiger Overhead sein damit das generisch Funktioniert und die Fehlermeldungen sind unlesbar. Und überhaupt, Operatorüberladung ist ja das schlimmste, da kann man ja den Datentyp nicht erkennen. Und die IOStreams, die std::string's, die std::vector<>s, die Algorithmen, alles Hexenwerk. Verbrennen sollte man es.

Ich habe kein Problem damit kritische Konzepte auch wieder aus Sprachen zu verbannen und als Irrweg zu kennzeichnen. Exceptions wäre für mich ein solches Konzept.

Ich habe mir Exceptions angesehen und direkt die Probleme gesehen und sie später im Beruf in genau der vorhergesagten Dramatik wiedergefunden - produziert von ausgebildeten Informatikern. Exceptions sind allgemein anerkannter und legitimierter Spaghetticode im Fehlerfall. Um Redundanzen zu vermeiden (gleicher Fehler, eine Behandlung) gibt es bessere Konzepte (Funktionen), die die Information, wo der Fehler aufgetreten ist, ebenfalls verwalten können (Parameter).

Es ist genausowenig perfekt, aber es ist unkomplizierter, denn es funktioniert ohne quer durch den Stack zu springen. Fehler sind im Code benannt und aufgeführt, statt "Fehler" zu brüllen und dann zu gucken, ob sich irgendeine der Funktionen auf dem Stack vielleicht dafür interessiert.

Das ist meine Meinung und von mir gemachte Erfahrung.