exit und return
-
tweenki schrieb:
...
zu was zählt man alles exceptions? ....Mach's Dir doch nicht so schwer !
Dir ging es doch um eine konkrete Situation, in der Du sagst "Hier will ich gar nicht mehr weitermachen" ... und da wirfst Du halt eine Exception.Eine "allgemeingültige und vollständige" Regel gibt's sowieso nicht. Davon zeugen z.B. die ewig langen Threads zu diesem Thema hier im Forum.
Am Besten machst Du erstmal selbst Erfahrungen mit dem Thema.Gruß,
Simon2.
-
tweenki schrieb:
kennt jemand ein tut wo das gut erklärt wird?
Eine Exception wirft man immer dann, wenn (Design by Contract sollte man im Hinterkopf haben) man die Postcondition einer Funktion/Methode nicht einhalten kann.
Was den konkreten Einsatz von Exceptions anbelangt. Unbedingt die Bücher von Herb Sutter anschauen, da man einige Regeln beachten muß, damit die eigenen Klassen exception safe bzw. exception neutral sind.
Wenn eine Exception geworfen wird, beginnt das sogenannte "stack unwinding", alle Objekte auf dem Stack werden destruiert und die Ausführung "springt im Stack zurück" solange bis irgend eine Stelle im Programm die Exception abfängt. Im schlimmsten Fall wird das Programm terminiert. Leider sind Zeiger PODs und damit passiert mit ihnen exakt gar nichts, es können so Speicherlöcher entstehen. Deshalb sollte man SmartPointer o.ä. einsetzen. Was alles zu beachten ist steht in recht gut erklärt in den Büchern von Sutter.
-
Fellhuhn schrieb:
return ist nur für Funktionen/Methoden, nicht für das eigentliche Programm.
Der saubere Weg ein Programm zu verlassen ist es aus main zu beenden, entweder implizit oder durch das explizite return mit Code.
exit hat den häßlichen Seiteneffekt, daß die Destruktoren von statischen Objekten nicht aufgerufen werden. Wenn man irgend welche Singletons ö.ä. hat, kann das problematisch sein.
-
~john schrieb:
Fellhuhn schrieb:
return ist nur für Funktionen/Methoden, nicht für das eigentliche Programm.
Der saubere Weg ein Programm zu verlassen ist es aus main zu beenden, entweder implizit oder durch das explizite return mit Code.
exit hat den häßlichen Seiteneffekt, daß die Destruktoren von statischen Objekten nicht aufgerufen werden. Wenn man irgend welche Singletons ö.ä. hat, kann das problematisch sein.
Habe ich was anderes behauptet?
-
Fellhuhn schrieb:
~john schrieb:
Fellhuhn schrieb:
return ist nur für Funktionen/Methoden, nicht für das eigentliche Programm.
Der saubere Weg ein Programm zu verlassen ist es aus main zu beenden, entweder implizit oder durch das explizite return mit Code.
exit hat den häßlichen Seiteneffekt, daß die Destruktoren von statischen Objekten nicht aufgerufen werden. Wenn man irgend welche Singletons ö.ä. hat, kann das problematisch sein.
Habe ich was anderes behauptet?
Naja, es hatte sich schon so angehört als würdest du exit für das Beenden in betracht ziehen.
Un der Unterschied zwischen exit und return ist etwa so, als wenn man in ein Hochhaus mehrere Treppen und Türen hinter sich gebracht hat, und sich dann überlegt wie man wieder das Haus verlässt:
return: Man geht wieder durch die Türen und Treppen zurück und verlässt damit das Hochhaus.
exit: Man nimmt das nächstbeste Fenster.Ja, es kann gut gehen. Aber mit Sicherheit nicht immer ;p
cu André
-
Eben, wenn du du mit "return" die letzte Treppe nimmst, bist du da wo du auch durchs "exit" im 20. Stock angekommen wärst. Allerdings in einem etwas unschöneren Zustand.
exit braucht man eigentlich nicht, Exceptions können das ebenso, und dazu sauber, regeln.
Wobei mir bei den Exceptions bei C++ immernoch das finally fehlt...
-
Fellhuhn schrieb:
Wobei mir bei den Exceptions bei C++ immernoch das finally fehlt...
Wobei du die meisten derartigen Situationen durch RAII lösen kannst - am Funktionanfang legst du ein Objekt an und im Destuktor führt es alle notwendigen Aufräumarbeiten auf (und der wird sowohl im Regelfall als auch beim Stack Unwinding ausgeführt).
-
Wirkt unsauber aber sicher eine bessere Möglichkeit als den CleanUp-Code mehrfach aufzuführen.
-
Fellhuhn schrieb:
Wirkt unsauber aber sicher eine bessere Möglichkeit als den CleanUp-Code mehrfach aufzuführen.
finally wälzt die Veranwortung wieder auf den Nutzer der Klasse und nicht auf den Designer einer Klasse ab. Die Realität zeigt, daß der Nutzer sich mit den Problemen nicht herumschlagen will. Insofern ist finally schlechter als RAII.
-
~john schrieb:
finally wälzt die Veranwortung wieder auf den Nutzer der Klasse und nicht auf den Designer einer Klasse ab. Die Realität zeigt, daß der Nutzer sich mit den Problemen nicht herumschlagen will. Insofern ist finally schlechter als RAII.
Weshalb ich auch der Meinung bin C++ braucht kein finally. Das verleitet nur zu unsauberer Programmierung
-
~john schrieb:
exit hat den häßlichen Seiteneffekt, daß die Destruktoren von statischen Objekten nicht aufgerufen werden. Wenn man irgend welche Singletons ö.ä. hat, kann das problematisch sein.
du verwechselst das verhalten mit abort.
exit ruft die destruktoren von statischen objekten sehr wohl auf.
nur automatische objekte müssen nicht unbedingt alle zerstört werden.btw. um sicher zu gehen, dass das passiert, empfiehlt der standard das werfen einer ausnahme, die in main gefangen wird. dort kann man ja dann auch exit aufrufen, wenn man lust hat (
)
-
LordJaxom schrieb:
~john schrieb:
finally wälzt die Veranwortung wieder auf den Nutzer der Klasse und nicht auf den Designer einer Klasse ab. Die Realität zeigt, daß der Nutzer sich mit den Problemen nicht herumschlagen will. Insofern ist finally schlechter als RAII.
Weshalb ich auch der Meinung bin C++ braucht kein finally. Das verleitet nur zu unsauberer Programmierung
Um nicht nochmal dasselbe zu schreiben: 100%
Gruß,
Simon2.
-
queer_boy schrieb:
du verwechselst das verhalten mit abort.
Mag sein, jedenfalls bleibt bei exit ein anderer Pferdefuß im Spiel, das Stack unwinding wird nicht gemacht. Ergo, läßt man von exit lieber die Finger. Es kann nichts, was return aus main nicht auch könnte. abort kann ja zu Debugging Zwecken ganz brauchbar sein.