(Un-)Sinn von Exceptions

Algorithmen, Sprachunabhängige Diskussionen zu Konzepten, Programmiersprachen-Design
Benutzeravatar
fat-lobyte
Beiträge: 1398
Registriert: Sa Jul 05, 2008 12:23 pm
Wohnort: ::1
Kontaktdaten:

(Un-)Sinn von Exceptions

Beitrag von fat-lobyte » Fr Jul 25, 2008 7:56 am

Dirty Oerti hat geschrieben:
Wieviele Tragflächen hat das Auto und glaubst Du es wird fliegen?
Nunja...aber wenn der Programmierer sein Auto dermaßen vergewaltigt ist er eigntl selber Schuld.
Du bist also im Grunde genommen gegen Casten, weil man damit als Programmierer "Mist bauen" kann?
Eine Programmiersprache muss seinen Programmierer unterstützen. Sie muss schlechte Designs schwierig machen, gute Designs Fördern. Das gleiche gilt für kleinere Fehler. Klar können Zeiger alles was Referenzen können, und man würde ganz ohne Referenzen auskommen. Referenzen bieten aber Sicherheiten, die Zeiger nicht bieten.

[
In C gibt es noch einen: Fehlerbehandlung mit ressourcenfreigabe. Stell dir vor, du hast in einer Funktion einen FILE* offen, und hast dutzende möglichkeiten für Fehler. In C++ gäbe es exceptions, in C müsstest du entweder: in jeden if(fehler) den FILE* schließen, oder eben mit goto an das ende der Funktion springen. Ich glaube das ist nicht unbedingt die schlechteste Möglichkeit.
Haters gonna hate, potatoes gonna potate.

Benutzeravatar
Xin
nur zu Besuch hier
Beiträge: 8862
Registriert: Fr Jul 04, 2008 11:10 pm
Wohnort: /home/xin
Kontaktdaten:

Re: C:Ausdrücke

Beitrag von Xin » Fr Jul 25, 2008 11:41 am

fat-lobyte hat geschrieben:In C gibt es noch einen: Fehlerbehandlung mit ressourcenfreigabe. Stell dir vor, du hast in einer Funktion einen FILE* offen, und hast dutzende möglichkeiten für Fehler. In C++ gäbe es exceptions, in C müsstest du entweder: in jeden if(fehler) den FILE* schließen, oder eben mit goto an das ende der Funktion springen. Ich glaube das ist nicht unbedingt die schlechteste Möglichkeit.
Ich bin immer wieder erstaunt, was man Exceptions alles zutraut.
Wer soll denn eine Exception werfen, wenn Du ein FILE * nicht schließt?
Merke: Wer Ordnung hellt ist nicht zwangsläufig eine Leuchte.

Ich beantworte keine generellen Programmierfragen per PN oder Mail. Dafür ist das Forum da.

Benutzeravatar
Kerli
Beiträge: 1456
Registriert: So Jul 06, 2008 10:17 am
Wohnort: Österreich
Kontaktdaten:

Re: C:Ausdrücke

Beitrag von Kerli » Fr Jul 25, 2008 12:43 pm

Xin hat geschrieben:
fat-lobyte hat geschrieben:In C gibt es noch einen: Fehlerbehandlung mit ressourcenfreigabe. Stell dir vor, du hast in einer Funktion einen FILE* offen, und hast dutzende möglichkeiten für Fehler. In C++ gäbe es exceptions, in C müsstest du entweder: in jeden if(fehler) den FILE* schließen, oder eben mit goto an das ende der Funktion springen. Ich glaube das ist nicht unbedingt die schlechteste Möglichkeit.
Ich bin immer wieder erstaunt, was man Exceptions alles zutraut.
Wer soll denn eine Exception werfen, wenn Du ein FILE * nicht schließt?
In C++ sollte man bei einem Fehler im Normalfall eine Exception werfen, und da man unter C++ auch nicht mehr mit FILE * sondern mit streams arbeitet wird durch das stackunwinding bei einer Exception auch der Destruktur des offenen Streams aufgerufen, der diesen dann auch schließt.
"Make it idiot-proof and someone will invent an even better idiot." (programmers wisdom)

OpenGL Tutorials und vieles mehr rund ums Programmieren: http://www.tomprogs.at

Benutzeravatar
Xin
nur zu Besuch hier
Beiträge: 8862
Registriert: Fr Jul 04, 2008 11:10 pm
Wohnort: /home/xin
Kontaktdaten:

Re: C:Ausdrücke

Beitrag von Xin » Fr Jul 25, 2008 5:06 pm

Kerli hat geschrieben:In C++ sollte man bei einem Fehler im Normalfall eine Exception werfen, und da man unter C++ auch nicht mehr mit FILE * sondern mit streams arbeitet wird durch das stackunwinding bei einer Exception auch der Destruktur des offenen Streams aufgerufen, der diesen dann auch schließt.
In der Aussage stecken mehrere Fehler.
Fangen wir hinten an: Destrukturen werden beim Stackaufräumen nur dann gerufen, wenn ein Objekt auf dem Stack liegt. Und ein IOStream * hat genausowenig einen Destruktor wie ein FILE *. Bei einem Fehler sollte im Normalfall keine Exception geworfen werden, sondern im Falle einer Ausnahme, darum heißen die Dinger auch Exception und nicht Error oder Failure. Wenn ich eine Datei nicht finde, die ich öffnen will, dann ist das keine Exception, sondern durchaus zu erwarten. Wenn ich als Programm meine eigene Installation nicht finde, dann ist das eine Ausnahme, denn schließlich wurde ich gestartet und kann damit davon ausgehen, dass ich woh installiert wurde.

Exceptionhandling ist eine absolute Fehlentwicklung.

Ganz einfach aus dem Grund, da Exceptions zusammengefasst werden können, die Behandlung häufig weitergereicht wird und wenn eine Exception erstmal zwei Level durchschlagen hat, weiß niemand mehr, was da eigentlich passiert ist und wie man auf die Exception reagieren kann, was bedeutet, dass man die Exception nur weiterreichen kann. Man hätte das Programm auch einfach abschmieren lassen können, das hätte zur Laufzeit im Regelfall Zeit gespart und im Fehlerfall hätte es keinen Unterschied gemacht.
Merke: Wer Ordnung hellt ist nicht zwangsläufig eine Leuchte.

Ich beantworte keine generellen Programmierfragen per PN oder Mail. Dafür ist das Forum da.

Benutzeravatar
Kerli
Beiträge: 1456
Registriert: So Jul 06, 2008 10:17 am
Wohnort: Österreich
Kontaktdaten:

Re: C:Ausdrücke

Beitrag von Kerli » Fr Jul 25, 2008 7:39 pm

Xin hat geschrieben: Fangen wir hinten an: Destrukturen werden beim Stackaufräumen nur dann gerufen, wenn ein Objekt auf dem Stack liegt. Und ein IOStream * hat genausowenig einen Destruktor wie ein FILE *.
Im Normalfall verwendet man ja auch keinen Zeiger auf einen Stream sondern direkt einen Stream...
Xin hat geschrieben: Bei einem Fehler sollte im Normalfall keine Exception geworfen werden, sondern im Falle einer Ausnahme, darum heißen die Dinger auch Exception und nicht Error oder Failure. Wenn ich eine Datei nicht finde, die ich öffnen will, dann ist das keine Exception, sondern durchaus zu erwarten. Wenn ich als Programm meine eigene Installation nicht finde, dann ist das eine Ausnahme, denn schließlich wurde ich gestartet und kann damit davon ausgehen, dass ich woh installiert wurde.
Ich sag ja auch nicht, dass man jeden Fehler mit Exceptions behandeln muss, aber es gibt durchaus viele sinnvolle Anwendungen.
Xin hat geschrieben: Exceptionhandling ist eine absolute Fehlentwicklung.

Ganz einfach aus dem Grund, da Exceptions zusammengefasst werden können, die Behandlung häufig weitergereicht wird und wenn eine Exception erstmal zwei Level durchschlagen hat, weiß niemand mehr, was da eigentlich passiert ist und wie man auf die Exception reagieren kann, was bedeutet, dass man die Exception nur weiterreichen kann. Man hätte das Programm auch einfach abschmieren lassen können, das hätte zur Laufzeit im Regelfall Zeit gespart und im Fehlerfall hätte es keinen Unterschied gemacht.
Also ich finde, dass Exceptions eine gute Möglichkeit zur Fehlerbehandlung sind. Also was in C teilweise für Fehlerbehandlung durchgeführt wird ist ja echt grauenhaft. Du brauchst dir nur einmal die Überprüfung auf Fehler durch das Missbrauchen des Rückgabewertes anschauen. Schließlich hat ja ein Rückgabewert die Aufgabe ein Ergebnis zu liefern und nicht den Fehlercode des Funktionsaufrufes.
Und warum sollte man Fehler nicht weiterreichen? Es wird ja irrsinnig unübersichtlich wenn man zb bei jedem Mal Speicher anfordern überprüft, ob man ihn auch bekommen kann, da kann man den Fehler doch auch ein paar Ebenen höher auffangen und dann darauf reagieren. Damit man weis woher ein Fehler kommt, kann man ja sonst auch noch trace backing einbauen, was mit C bzw. ohne Exceptions nur mit viel Mehraufwand möglich wäre.
"Make it idiot-proof and someone will invent an even better idiot." (programmers wisdom)

OpenGL Tutorials und vieles mehr rund ums Programmieren: http://www.tomprogs.at

Benutzeravatar
Xin
nur zu Besuch hier
Beiträge: 8862
Registriert: Fr Jul 04, 2008 11:10 pm
Wohnort: /home/xin
Kontaktdaten:

Re: C:Ausdrücke

Beitrag von Xin » Fr Jul 25, 2008 7:54 pm

Kerli hat geschrieben:
Xin hat geschrieben: Fangen wir hinten an: Destrukturen werden beim Stackaufräumen nur dann gerufen, wenn ein Objekt auf dem Stack liegt. Und ein IOStream * hat genausowenig einen Destruktor wie ein FILE *.
Im Normalfall verwendet man ja auch keinen Zeiger auf einen Stream sondern direkt einen Stream...
Man arbeitet aber nicht immer mit Streams, sondern häufig mit Dingen, die man anfordern muss und danach wieder freigeben, zum Beispiel alles, was man mit new anfordert, alles worauf man nur einen Zeiger oder eine Referenz erhält.
Und da gibt es eine Menge Dinge, dass Exceptions da streams aufräumen... Super *thumps up*
Kerli hat geschrieben:
Xin hat geschrieben: Exceptionhandling ist eine absolute Fehlentwicklung.

Ganz einfach aus dem Grund, da Exceptions zusammengefasst werden können, die Behandlung häufig weitergereicht wird und wenn eine Exception erstmal zwei Level durchschlagen hat, weiß niemand mehr, was da eigentlich passiert ist und wie man auf die Exception reagieren kann, was bedeutet, dass man die Exception nur weiterreichen kann. Man hätte das Programm auch einfach abschmieren lassen können, das hätte zur Laufzeit im Regelfall Zeit gespart und im Fehlerfall hätte es keinen Unterschied gemacht.
Also ich finde, dass Exceptions eine gute Möglichkeit zur Fehlerbehandlung sind. Also was in C teilweise für Fehlerbehandlung durchgeführt wird ist ja echt grauenhaft. Du brauchst dir nur einmal die Überprüfung auf Fehler durch das Missbrauchen des Rückgabewertes anschauen. Schließlich hat ja ein Rückgabewert die Aufgabe ein Ergebnis zu liefern und nicht den Fehlercode des Funktionsaufrufes.
Wer sagt, dass die Information Erfolg oder Mißerfolg kein Ergebnis ist?
Kerli hat geschrieben:Und warum sollte man Fehler nicht weiterreichen? Es wird ja irrsinnig unübersichtlich wenn man zb bei jedem Mal Speicher anfordern überprüft, ob man ihn auch bekommen kann, da kann man den Fehler doch auch ein paar Ebenen höher auffangen und dann darauf reagieren.
Wie denn?

Ich habe was in Auftrag gegeben und irgendwo gab's keinen Speicher. Ist das schlimm? Ist mein Auftrag jetzt gescheitert oder sind quasi Dekorationen nicht ausgeführt worden. Und wer hat keinen Speicher bekommen? Habe ich Teilergebnisse? Welcher Auftrag ist überhaupt gescheitert, schließlich stehen zwischen try und Catch ja mehrere Anweisungen. ES WIRD JA NOCH VIEL IRRSINNIGER, WENN JEDE ANWEISUNG EINEN EIGENEN TRY UND CATCH BEREICH HAT, aber blöderweise ist das die einzige Möglichkeit, mit Exceptions sauber zu programmieren und weil das so ist, sieht eine sauberes Try-Catch Fehler-Handling leider so aus, dass was in C fünf Zeilen sind, mit dem ganzen Try-Catch eine Bildschirmseite ist. Und damit das eben doch keine Bildschirmseite ist, liest Du in PROFESSIONELLEN Sourcecodes häufig catch( Exception e ) { throw e; } oder noch geiler catch( Exception e ) { throw FirmaException( e ); } oder ganz perfekt: catch( Exception e ) {}.
Das ist, was realistisch mit Exceptions passiert. Nichts.
Kerli hat geschrieben:Damit man weis woher ein Fehler kommt, kann man ja sonst auch noch trace backing einbauen, was mit C bzw. ohne Exceptions nur mit viel Mehraufwand möglich wäre.
Und was machst Du mit dem Backtrace? Dem User um die Ohren werfen, weil zu retten ist da nix.
Und den Stacktrace, den habe ich auch, wenn ich's einfach knallen lasse.
Merke: Wer Ordnung hellt ist nicht zwangsläufig eine Leuchte.

Ich beantworte keine generellen Programmierfragen per PN oder Mail. Dafür ist das Forum da.

Benutzeravatar
Kerli
Beiträge: 1456
Registriert: So Jul 06, 2008 10:17 am
Wohnort: Österreich
Kontaktdaten:

Re: C:Ausdrücke

Beitrag von Kerli » Fr Jul 25, 2008 8:15 pm

Xin hat geschrieben:
Kerli hat geschrieben: Im Normalfall verwendet man ja auch keinen Zeiger auf einen Stream sondern direkt einen Stream...
Man arbeitet aber nicht immer mit Streams, sondern häufig mit Dingen, die man anfordern muss und danach wieder freigeben, zum Beispiel alles, was man mit new anfordert, alles worauf man nur einen Zeiger oder eine Referenz erhält.
Und da gibt es eine Menge Dinge, dass Exceptions da streams aufräumen... Super *thumps up*
Aber da man in C++ alles meistens in Klassen hat, kann man die mit new angeforderten Speicherbereiche im Destruktor wieder freigeben lassen.

Code: Alles auswählen

DemoClass *demo;
try
{
  demo = new DemoClass();
  demo->run();
}
catch(std::bad_alloc&)
{
  delete demo;
}
In diesem Beispiel ist das ganze mit Exceptions doch sehr schön gelöst. Weil was würdest du machen, wenn jetzt im Konstruktor der Klasse und in der Methode 'run()' Speicher mit 'new' angefordert wird, und das fehlschlägt. Also mir fällt keine schöne Möglichkeit ohne Exceptions ein.
Xin hat geschrieben:
Kerli hat geschrieben: Also ich finde, dass Exceptions eine gute Möglichkeit zur Fehlerbehandlung sind. Also was in C teilweise für Fehlerbehandlung durchgeführt wird ist ja echt grauenhaft. Du brauchst dir nur einmal die Überprüfung auf Fehler durch das Missbrauchen des Rückgabewertes anschauen. Schließlich hat ja ein Rückgabewert die Aufgabe ein Ergebnis zu liefern und nicht den Fehlercode des Funktionsaufrufes.
Wer sagt, dass die Information Erfolg oder Mißerfolg kein Ergebnis ist?
Natürlich gibt es solche Fälle auch, aber nimm zb einmal 'sqrt'. Hier bekommst du im Fehlerfall einen speziellen Wert als Rückgabewert, und da wäre es doch mit Exceptions viel schöner, als wenn du immer überprüfen musst ob der Rückgabewert gültig ist.
Xin hat geschrieben:
Kerli hat geschrieben:Und warum sollte man Fehler nicht weiterreichen? Es wird ja irrsinnig unübersichtlich wenn man zb bei jedem Mal Speicher anfordern überprüft, ob man ihn auch bekommen kann, da kann man den Fehler doch auch ein paar Ebenen höher auffangen und dann darauf reagieren.
Wie denn?

Ich habe was in Auftrag gegeben und irgendwo gab's keinen Speicher. Ist das schlimm? Ist mein Auftrag jetzt gescheitert oder sind quasi Dekorationen nicht ausgeführt worden. Und wer hat keinen Speicher bekommen? Habe ich Teilergebnisse? Welcher Auftrag ist überhaupt gescheitert, schließlich stehen zwischen try und Catch ja mehrere Anweisungen. ES WIRD JA NOCH VIEL IRRSINNIGER, WENN JEDE ANWEISUNG EINEN EIGENEN TRY UND CATCH BEREICH HAT, aber blöderweise ist das die einzige Möglichkeit, mit Exceptions sauber zu programmieren und weil das so ist, sieht eine sauberes Try-Catch Fehler-Handling leider so aus, dass was in C fünf Zeilen sind, mit dem ganzen Try-Catch eine Bildschirmseite ist. Und damit das eben doch keine Bildschirmseite ist, liest Du in PROFESSIONELLEN Sourcecodes häufig catch( Exception e ) { throw e; } oder noch geiler catch( Exception e ) { throw FirmaException( e ); } oder ganz perfekt: catch( Exception e ) {}.
Das ist, was realistisch mit Exceptions passiert. Nichts.
Das kommt natürlich auf den Programmierer an. Und man muss ja auch nicht nur Exceptions verwenden, sondern versuchen den richtigen Mittelweg zu finden.
Xin hat geschrieben:
Kerli hat geschrieben:Damit man weis woher ein Fehler kommt, kann man ja sonst auch noch trace backing einbauen, was mit C bzw. ohne Exceptions nur mit viel Mehraufwand möglich wäre.
Und was machst Du mit dem Backtrace? Dem User um die Ohren werfen, weil zu retten ist da nix.
Und den Stacktrace, den habe ich auch, wenn ich's einfach knallen lasse.
Naja, eher in ein Logfile schreiben, weil wenn du weist woher ein Fehler kommt ist es viel einfacher die Ursache dafür zu finden.
"Make it idiot-proof and someone will invent an even better idiot." (programmers wisdom)

OpenGL Tutorials und vieles mehr rund ums Programmieren: http://www.tomprogs.at

Benutzeravatar
Xin
nur zu Besuch hier
Beiträge: 8862
Registriert: Fr Jul 04, 2008 11:10 pm
Wohnort: /home/xin
Kontaktdaten:

Re: C:Ausdrücke

Beitrag von Xin » Fr Jul 25, 2008 9:34 pm

Kerli hat geschrieben:Aber da man in C++ alles meistens in Klassen hat, kann man die mit new angeforderten Speicherbereiche im Destruktor wieder freigeben lassen.

Code: Alles auswählen

DemoClass *demo;
try
{
  demo = new DemoClass();
  demo->run();
}
catch(std::bad_alloc&)
{
  delete demo;
}
In diesem Beispiel ist das ganze mit Exceptions doch sehr schön gelöst. Weil was würdest du machen, wenn jetzt im Konstruktor der Klasse und in der Methode 'run()' Speicher mit 'new' angefordert wird, und das fehlschlägt. Also mir fällt keine schöne Möglichkeit ohne Exceptions ein.
Wie willst Du eine Meinung vertreten, ob etwas besser ist, wenn Du aus mangelnden Wissen nichtmals keine Wahl hast?
Nichts für ungut, aber Dein Beispiel ist keine schöne Lösung, sie ist sogar falsch. Wenn ich Lust hätte, könnte ich jetzt anfangen Fragen zu stellen und solange Du nicht nachdenkst, dokterst Du da zwei, drei weitere falsche Lösungen zurecht.
Warum gibst Du den Speicher im catch-Bereich frei? Wenn Du keinen Speicher bekommen hast, wieso gibst Du ihn frei? Dafür gibst Du ihn nicht frei, nachdem run() erfolgreich gelaufen ist.

Deine Schöne Lösung hat so einige Schönheitsfehler. Wenn Du eine bad_alloc bekommst, dann kannst Du nicht unterscheiden, ob Du nun das Objekt nicht erhalten hast, oder ob run() Mist gebaut hat. Füge das doch bitte mal hinzu, so dass Du das unterscheiden kannst. So sieht das ohne Exceptions aus.

Code: Alles auswählen

DemoClass * demo;

demo = new (std::nothrow) DemoClass();
if( demo ) 
  if( demo->run() ) printf( "Success\n" );
  else              printf( "Failed\n" );
else                printf( "No Memory\n" );

delete demo;
Meine Version gibt übrigens den Speicher auch dann frei, wenn er Speicher bekommen hat... sie liefert viel genauere Informationen und sie ist schon jetzt kürzer als die Exceptions-Version.
Schreib mal Deine Exceptionsversion dazu und sag mir dann was Du persönlich als übersichtlicher empfindest.
Kerli hat geschrieben:Natürlich gibt es solche Fälle auch, aber nimm zb einmal 'sqrt'.
SUPER!!!, dass Du grade sqrt nimmst, ich nehme das auch immer als Beispiel, um aufzuzeigen, wie scheiße Exceptions sind, aber dann heißt es immer, dass das Beispiel ja schlecht gewählt wäre...
Kerli hat geschrieben:Hier bekommst du im Fehlerfall einen speziellen Wert als Rückgabewert, und da wäre es doch mit Exceptions viel schöner, als wenn du immer überprüfen musst ob der Rückgabewert gültig ist.
Okay, dann machen wir mal... Damit eine Exception kommen kann, muss sie geworfen werden, also muss sqrt() immer prüfen, ob ein positiver Wert übergeben wurde then rechnen else throw Exception.
Die Alternative wäre, ich prüfe, ob mein Wert negativ ist, gebe ich einen negativen Wert ein, erhalte ich ein schwachsinniges Ergebnis von sqrt.
Wenn ich prüfe, weiß ich, dass negative Werte möglich sind, kann vor sqrt() eingreifen und den Algorithmus z.B. mit x = -x; korrekt ablaufen lassen. Okay, dafür muss ich wissen, was ich da programmiere... Wenn da der Exceptionprogrammierer auch denken muss, dann prüft er aber zweimal, also eine Überprüfung ist total für den Arsch... zusätzlich hantiert er laufend mit try rum, das kostet auch noch Rechenzeit.

Nehmen wir mal ein Beispiel, wo es nicht so um Effizients ankommt, zum Beispiel 3D Berechnungen. Da nehmen wir einen 3D Vector und wollen die Länge wissen. Für unsere Kleineren und die, denen die Vektorrechnung grade abhanden gekommen ist:
Vektorlänge = sqrt( x*x + y*y + z*z );
Multipliziert man zwei positive Zahlen, kommt was positives raus, sind beide Zahlen negativ kommt was positives raus. Addiert man positive Zahlen, kommt auch was positives raus. In diesem Algorithmus kann und da kannst Du Dich auf den Kopf stellen, es kann NIEMALS eine negative Zahl in sqrt() reingehen. Während ich mich also um gar nichts kümmeren muss, wirfst Du erstmal Rechenzeit raus in dem Du mit 'try' anfängst (ja, diese Anweisung kostet...) und anschließend stellst innerhalb von sqrt() eine vollkommen sinnlose Frage, nämlich, ob der Parameter vielleicht negativ ist, und in Java schreibst Du zusätzlich noch zwangsweise eine Fehlerbehandlung für eine Fehler, der - ich erwähnte es bereits - NIEMALS kommen kann.
Entwickler kosten ja nix, die haben ja sonst nix zu tun und ich weiß nicht, ob absolut sinnentleerter Code für Fehlerbehandlungen die Übersicht verbessert.
Hast Du nun mehrere sinnlose Fehlerabfragen, hat ein Entwickler die Schnauze voll, weil da auf einmal fünf, sechs sinnfreie catch( bla ) {} stehen und fasst das ganze in catch( Exception ) {} zusammen. Alles, was kommen kann, wird ja davor behandelt... dummerweise kommt in der nächsten Version wieder was neues, was sich dann in catch( Exception ) {} verliert und für totale Verwirrung sorgt. Es kommt ja keine Exception, aber leider stimmt die Rechnung auch nicht.
Im Idealfall stimmt die Rechnung fast, weil nur ein kleiner Teil der Rechnung Ärger machte... Kennst Du diese Werbung, wo die beiden Brückenteile von beiden Ufern aus gebaut werden und die beiden Teile passen in der Mitte des Flusses auch fast zusammen.
DAS ist Fehlerbehandlung mit Exceptions in der Realität.

Zurück zum sqrt() Problem: Zum Glück wissen wir, dass für 3D Berechnungen große Rechner angeschafft werden und da sind die paar Takte vermutlich nicht erwähnenswert, wo sie ja nur in einer der absolut grundlegendsten Funktionen verschwendet werden.
Kerli hat geschrieben:
Xin hat geschrieben:Das ist, was realistisch mit Exceptions passiert. Nichts.
Das kommt natürlich auf den Programmierer an.
Nein, das kommt nicht eben nicht auf DEN Programmierer an, sondern es kommt auf alle Programmierer in einem Projekt an. Wenn einer von x Programmierern Exceptions nicht sauber ausformuliert und wenn Du das das Popelsbeispiel da oben sauber ausformuliert hast, dann wirst Du verstehen, dass richtige Algorithmen so gut wie nie sauber in Exceptions ausformuliert werden, also wenn ein Programmierer von X das schleifen lässt, dann war es das. Dann ist's vorbei. Dann kommt irgendwo eine Exception vorbeigeflogen, mit der ein anderer Programmierer nichts anfangen kann, also was soll er tun? Er reicht sie weiter und der nächste Programmierer kann nichts damit anfangen. Nicht selten landet sie dann wie oben beschrieben in irgendeinem catch( Exception e ) {}. Kurz: Fehler behoben, Lösung vorhanden... gut vielleicht nicht für das gestellte Problem, aber das Programm verrät dieses Detail es bestimmt keinem mehr.

Du hast keine Ahnung, woher bad_alloc bei Dir im Beispiel fliegt, Du befindest Dich in Deinem catch Block absolut im Blindflug und nennst das auch noch eine schöne Lösung. Ich verstehe die Idee hinter Exceptions und sie ist gut. Aber vor allem sind Exceptions ein Konzeptproblem, denn sie helfen nicht die Fehlerhandhabung zu verbessern, sondern sie öffnen Scheunentore, um sie zu vermurksen.
Die Haupterrungenschaft, die Exception geleistet haben ist dass das Programm nicht einfach so abschmiert, sondern vorher ein PopUp-Fenster aufgeht, dass erklärt, dass das Programm abgeschmiert ist, meine Daten im Arsch sind - tut uns leid - und ich das Programm mit 'Ok' nun beenden kann.
Unter'm Strich ist genau das die Leistung, die Exceptions bringen. Eine Abnahme der Fehlerbehandlung, weil sie zu aufwendig wird und eine absolut zynische Meldung an den Benutzer.
Kerli hat geschrieben:
Xin hat geschrieben:
Kerli hat geschrieben:Damit man weis woher ein Fehler kommt, kann man ja sonst auch noch trace backing einbauen, was mit C bzw. ohne Exceptions nur mit viel Mehraufwand möglich wäre.
Und was machst Du mit dem Backtrace? Dem User um die Ohren werfen, weil zu retten ist da nix.
Und den Stacktrace, den habe ich auch, wenn ich's einfach knallen lasse.
Naja, eher in ein Logfile schreiben, weil wenn du weist woher ein Fehler kommt ist es viel einfacher die Ursache dafür zu finden.
Dein und mein Porgramm sind weiterhin buggy und wir haben beide einen Stacktrace, nur Deins läuft langsamer. Wo genau ist jetzt der Vorteil bei den Exceptions?

Ganz ehrlich... ich halte nix von Exceptions, weil die keiner sauber ausprogrammieren will - siehe Dein eigenes Beispiel oben - und laufend erzählen mir die Leute, wie toll die sind. Dann lese ich in Effiziente C++ Programmierung die Kapitel zu Exceptions und sehe, was die an Rechenzeit verschwenden.
In meinen Augen, eine gut gemeinte Entwicklung, die leider in die falsche Richtung ging.
Ähnlich mit dem Operator-Prioritäten von | und ==. Die Idee war gut - aber die Idee, die die Sprachentwickler hatten, hat die Entwickler nicht interessiert und seitdem ärgert sich eine Generation nach der anderen, weshalb man die Prioritäten so bescheuert ausgelegt hat, dass man immer Klammern drumrumsetzen muss. Die Operatoren werden nämlich in der Regel für andere Dinge benutzt, als Kerningham und Ritchie vermutet hatten. Dumm gelaufen.
Exceptions sind Ausnahmen, aber sie werden nicht in Ausnahmen verwendet, ihre Verwendung ist - grade in Java - die Regel. Und da hakts.
Merke: Wer Ordnung hellt ist nicht zwangsläufig eine Leuchte.

Ich beantworte keine generellen Programmierfragen per PN oder Mail. Dafür ist das Forum da.

Benutzeravatar
Dirty Oerti
Beiträge: 2229
Registriert: Di Jul 08, 2008 5:05 pm
Wohnort: Thurndorf / Würzburg

Re: C:Ausdrücke

Beitrag von Dirty Oerti » Fr Jul 25, 2008 9:43 pm

Code: Alles auswählen

DemoClass *demo;
try
{
  demo = new DemoClass();
  demo->run();
}
catch(std::bad_alloc&)
{
  delete demo;
}

Das bringt, wie schon gemerkt, nicht gerade was.

Ich denke, das sollte (oder wollte) eher so aussehen, oder?

Code: Alles auswählen

DemoClass *demo;
demo = new DemoClass();
try
{
  demo->run();
}
catch()
{
  delete demo;
}
delete demo;
Für den Fall, das bei "run()" was schief geht...
Bei Fragen einfach an daniel[ät]proggen[Punkt]org
Ich helfe gerne! :)
----------
Wenn du ein Licht am Ende des Tunnels siehst, freu dich nicht zu früh! Es könnte ein Zug sein, der auf dich zukommt!
----
It said: "Install Win95 or better ..." So I installed Linux.

Benutzeravatar
Xin
nur zu Besuch hier
Beiträge: 8862
Registriert: Fr Jul 04, 2008 11:10 pm
Wohnort: /home/xin
Kontaktdaten:

Re: C:Ausdrücke

Beitrag von Xin » Fr Jul 25, 2008 9:47 pm

Dirty Oerti hat geschrieben:Ich denke, das sollte (oder wollte) eher so aussehen, oder?

Code: Alles auswählen

DemoClass *demo;
demo = new DemoClass();
try
{
  demo->run();
}
catch()
{
  delete demo;
}
delete demo;
Für den Fall, das bei "run()" was schief geht...
Wenn run() fehlschlägt, sorgt catch() dafür, dass es auch wirklich abschmiert ;-)
Fehlerbehandlung im wahrsten Sinne des Wortes ;-)
Merke: Wer Ordnung hellt ist nicht zwangsläufig eine Leuchte.

Ich beantworte keine generellen Programmierfragen per PN oder Mail. Dafür ist das Forum da.

Antworten