Alle möglichen Fehler abfangen? Auch nicht-Exceptions?
-
C++User123 schrieb:
...
Grundsätzlich: Dinge wie Division durch 0 oder eine Access Violation sind keine Ausnahmen im Sinne der meisten Sprachen, sondern Meldungen des Betriebssystems. In ANSI C++ gibt es keine Betriebssystemspezifischen Ausnahmen. Hierzu muss man auf Funktionen des Betriebssystems zurückgreifen, wenn C# dies kann hast du Glück gehabt.
Im Codegear C++ Builder wird eine Access Violation auch in eine VCL-Exception umgewandelt, das ist aber VCL-Spezifisch. Nur wird diese dann teilweise auch irgendwo "abgefangen" (Was wiederum auch nicht sonderlich toll ist).
Der Aufwand ALLE Ausnahmen (OS-Spezifisch, als auch die normalen C++ Exceptions) zu fangen ist sehr groß. Zudem ist es ohnehin besser zu versuchen das garkeine Fehler des Betriebssystems auftreten (Auch wenn das finden der Fehlerstelle lange dauern kann).
-
catcher schrieb:
Und ob dem User die Meldung präsentiert wird oder ein "aborted due to uncaught exception" ist dann auch egal.
Nicht ganz. Wenn die technische Fehlermeldung z.B. in einem Logfile gespeichert wird, kann das dem Entwickler helfen, den Fehler zu finden. Zumindest viel eher als "Programm funktioniert nicht mehr".
Ansonsten hast du natürlich Recht; Exceptions dazu einzusetzen, das Programm um jeden Preis weiterlaufen zu lassen, ist bestimmt das falsche Vorgehen.
-
Nexus schrieb:
catcher schrieb:
Und ob dem User die Meldung präsentiert wird oder ein "aborted due to uncaught exception" ist dann auch egal.
Nicht ganz. Wenn die technische Fehlermeldung z.B. in einem Logfile gespeichert wird, kann das dem Entwickler helfen, den Fehler zu finden. Zumindest viel eher als "Programm funktioniert nicht mehr".
Ansonsten hast du natürlich Recht; Exceptions dazu einzusetzen, das Programm um jeden Preis weiterlaufen zu lassen, ist bestimmt das falsche Vorgehen.
Genau. Danke für den Hinweis. Das wollte ich auch ähnlich so schreiben. Es ist halt schon ein Unterschied, ob ein Programm mit "aborted due to uncaught exception" oder mit "connection refused" abbricht. Der technisch versierte Benutzer kann vielleicht damit was anfangen oder der Support bekommt dann doch einen Hinweis.
-
Ich muss dazu nochmal ein paar Dinge klarstellen:
1. Natürlich läuft das Programm dann NICHT einfach weiter, sondern wird beendet. Der Unterschied ist aber dass es nicht einfach crasht sondern ich es kontrolliert beenden kann.
2. Ja ich habe nur dieses eine einzige Catch aus folgendem Grund: siehe 3.+4.
3. In .NET enthält die Exception Klasse auch Informationen über den Fehler, ich kann also auch in meiner Main noch aus dem Exception Objekt Infos auslesen wie: Name der Klasse in der die Ex aufgetreten ist, Name der Methode ja sogar die Zeile im Quellcode wo die Ex entstanden ist.
4. Natürlich wäre es sinnvoll die Exception möglichst nah am Ursprung zu behandeln. Allerdings ist das in meinem speziellen Programm nicht sinnvoll, das Programm soll bei einem Fehler - egal was für einem - beendet werden. Daher habe ich nur das eine catch.
So das erstmal dazu. Und dann finde ich es auch sinnvoll wenn sich der Programmierer Gedanken macht und keine Fehler auftreten lässt, das tue ich auch. Trotzdem können ja theoretisch immernoch irgendwann irgendwo Fehler auftreten, und für diesen Ausnahmefall hätte ich dann eben gerne diese Absicherung. Sozusagen als Lebensversicherung.
@ berniebutt: Aber wenn das Programm crasht dann kannst du doch den Outputstream von deinem Logging nicht mehr close()-en oder?? Oder übernimmt das Windows nach einem Crash etwa selbst?
-
C++User123 schrieb:
@ berniebutt: Aber wenn das Programm crasht dann kannst du doch den Outputstream von deinem Logging nicht mehr close()-en oder?? Oder übernimmt das Windows nach einem Crash etwa selbst?
Nein, bei einem crash macht das Programm keinen von dir programmiertes close().
Zumindest unter Windows bleiben die Einträge aber erhalten und können eingesehen werden. Ich mache das so und benutze keine exceptions nur nur selten debug.
-
berniebutt schrieb:
Zumindest unter Windows bleiben die Einträge aber erhalten und können eingesehen werden. Ich mache das so und benutze keine exceptions nur nur selten debug.
Nein. Sie bleiben nur bei Dir, weil Du nach jeder Zeile <<'\n'<<flush; machst und mit dem flush ein vorzeitiges (teures) Schreiben auf die Platte erzwingst.
-
volkard schrieb:
Nein. Sie bleiben nur bei Dir, weil Du nach jeder Zeile <<'\n'<<flush; machst und mit dem flush ein vorzeitiges (teures) Schreiben auf die Platte erzwingst.
Ist mir egal, jedes lange mühsame Fehlersuchen erscheint mir deutlich teurer als einige Millisekunden mehr!
-
berniebutt schrieb:
volkard schrieb:
Nein. Sie bleiben nur bei Dir, weil Du nach jeder Zeile <<'\n'<<flush; machst und mit dem flush ein vorzeitiges (teures) Schreiben auf die Platte erzwingst.
Ist mir egal, jedes lange mühsame Fehlersuchen erscheint mir deutlich teurer als einige Millisekunden mehr!
Das darfst Du. Es ging um "Zumindest unter Windows bleiben die Einträge aber erhalten". Es hat nichts mit Windows zu tun, sondern mit dem flushen.
-
volkard schrieb:
Das darfst Du. Es ging um "Zumindest unter Windows bleiben die Einträge aber erhalten". Es hat nichts mit Windows zu tun, sondern mit dem flushen.
Stimmt nicht ganz. Bei früheren Betriebssystemen waren im Falle eines Programmcrash die letzten Einträge meist kaputt. Ich denke aber, darum geht es hier nicht. Im Sinne der Fragestellung wollte ich allein auf den Wert einer eigenen Protokolldatei hinweisen. Ich meine, diese Mühe lohnt immer!
-
berniebutt schrieb:
volkard schrieb:
Das darfst Du. Es ging um "Zumindest unter Windows bleiben die Einträge aber erhalten". Es hat nichts mit Windows zu tun, sondern mit dem flushen.
Stimmt nicht ganz. Bei früheren Betriebssystemen waren im Falle eines Programmcrash die letzten Einträge meist kaputt.
Aber doch nicht, wenn man das Rausschreiben erzwingt, damals eher mit http://www.cplusplus.com/reference/clibrary/cstdio/fflush/