<stdexcept>
-
Naja, das mit der besseren Lesbarkeit ist ja Unsinnig. Es hat schon einen Sinn, das es mehrere Typen von Exceptions gibt. Man will damit erreichen, das man auf verschiedene FehlerTYPEN auch entsprechend reagieren kann. Sagen wir mal eine Funktion wirft Exceptions. Wie soll man auf unterschiedliche Fehler reagieren können, wenn es nur einen Exceptiontyp geben würde? Schwierig, oder?
try { foo(m); } catch(exception &e) { cout << "ehm, keine Ahnung was jetzt wirklich schief lief." << endl; }Aha? Um was handelt es sich denn jetzt? Ist jetzt in foo() Speicher reserviert worden der gescheitert ist? Oder ist mein übergebener Wert von m ungültig? Oder warum ist foo jetzt schief gegeangen?
Das nachfolgende ist doch schon besser, oder?
try { foo(m); } catch(bad_alloc &e1) { cout << "Verdammt, Sie haben nicht genug RAM!!!" << endl; foo_reset(); // mal alle Container löschen foo(m); } catch(invalid_argument &e2) { foo(321); // m scheint foo nicht gut zu bekommen, aber 321 ist immer richtig. :) }Also, der Sinn ist auch, das ich je nach Exceptiontyp auch verschieden reagieren kann. Es ist auch nicht immer so, das ich nur eine Fehlermeldung in einem catch-Block ausgeben muß. Ich kann ja bei einer exception auch einen alternativen Programmverlauf anschlagen, oder einen neuen Versuch mit anderen Parametern versuchen oder eine ganz andere Funktion aufrufen. Das geht aber nur, wenn ich den Ausnahmefall typisieren kann.
Bessere lesbarkeit... tsstsssss.
-
Artchi schrieb:
Wie soll man auf unterschiedliche Fehler reagieren können, wenn es nur einen Exceptiontyp geben würde? Schwierig, oder?
Umpf Jo hast Recht, vergessen zu erwähnen...
Aber schwierig ist das ja trotzdem nicht...Man kann schließlich einfach mit einem bestimmten Wert (gespeichert über ein Klassenelement) die Fehlersituation signalisieren
.
-
CodeFinder schrieb:
Aber schwierig ist das ja trotzdem nicht...Man kann schließlich einfach mit einem bestimmten Wert (gespeichert über ein Klassenelement) die Fehlersituation signalisieren
.Das wird dann aber unübersichtlich. außerdem werden exceptions dann nicht automatisch weitergeworfen wenn du sie nicht behandelst.
-
CodeFinder schrieb:
Artchi schrieb:
Wie soll man auf unterschiedliche Fehler reagieren können, wenn es nur einen Exceptiontyp geben würde? Schwierig, oder?
Umpf Jo hast Recht, vergessen zu erwähnen...
Aber schwierig ist das ja trotzdem nicht...Man kann schließlich einfach mit einem bestimmten Wert (gespeichert über ein Klassenelement) die Fehlersituation signalisieren .... und Du kannst nicht (oder nur sehr umständlich und wartungsaufwendig) "Gruppieren".
Es gibt halt Situationen, in denen Du Dich nur dafür interessierst, daß ein logical_error geflogen ist, während in anderen zwischen logical_DB_error und logical_Param_error unterschieden werden muß.
Per Vererbung bekommst Du das "geschenkt"....Gruß,
Simon2.
-
den fehlertyp kann man doch aus dem string ermitteln den what() zurückgibt.
-
Wobei jedoch nicht festgelegt ist, WAS in diesem Fehlerstring stehen muß (dagegen kannst du am jeweiligen Exception-Typ schonmal einstufen, was schief gelaufen sein könnte).
-
nichtvererber schrieb:
den fehlertyp kann man doch aus dem string ermitteln den what() zurückgibt.
Frickler
-
Ja also, anscheinend habt Ihr meinen Post nicht richtig gelesen (zum mindestens einige)...:
Ich bin doch gar nicht der Meinung, das Exception-Classes 'schlecht' sind, bzw. eine Lösung
durch 'Signalwerte' (-> Flags) besser wäre... . Es ging mir lediglich darum, zu zeigen, dass
es auch eine andere Möglichkeit gibt ("auf unterschiedliche Fehler [zu] reagieren"); habe also
eigentlich nur Stellung dazu genommen :Artchi schrieb:
[...]Wie soll man auf unterschiedliche Fehler reagieren können, wenn es nur einen Exceptiontyp geben würde?[...]
-
CodeFinder schrieb:
...
Ich bin doch gar nicht der Meinung, das Exception-Classes 'schlecht' sind, bzw. eine Lösung
durch 'Signalwerte' (-> Flags) besser wäre... ....Ja, deswegen ist es auch kein persönliches Widersprechen, wenn wir hier gleich die Nachteile dieser Vorgehensweise aufzeigen.
Gruß,
Simon2.
-
K, k