Ausnahmen bestägen die Regel
-
Aber leider nicht für mich...
MFC-Quelltext scheint meine Ausnahmen zu schlucken. Wenn in einem Message-Handler eine Ausnahme fliegt, werde ich zwar im Ausgabefenster des Debuggers per Nachricht darauf hingewiesen, allerdings passiert sonst nichts, das wird einfach geschluckt. Somit kann ich nichtmal sehen, weshalb und wo eine Ausnahme geworfen wurde. Habe ich meinen Debugger verkonfiguriert oder ist das etwas hakelig mit Ausnahmen in MFC?
-
Sind es unterschiedliche Threads?
-
Den hier habe ich gerade gefunden: O.O
-
Es sind Threads involviert, aber wenn ich mal selber einen try-Block drumpacke sieht man schnell, dass auch exceptions aus dem Message-Thread geschluckt werden.
-
Noch spezifischere Informationen:
http://blog.paulbetts.org/index.php/2010/07/20/the-case-of-the-disappearing-onload-exception-user-mode-callback-exceptions-in-x64/Und ich frage mich die ganze Zeit, wie man so Software entwickeln soll -.-
-
Also der letzte Artikel bezieht sich auf .NET.
Grundsätzlich muss Dir klar sein, dass bei einer Exception in einer Fenster-Prozedur natürlich auch OS Code im Stack liegt. Der ist aber eben nicht "C++ aware". Der kann also eine C++ Excpetion nicht behandeln. (SEH ist was anderes).
MFC Expection werden deshalb in der Fensterprozedur nicht geschluckt, sondern behandelt. Dazu gibt es die Funktion CWinApp::ProcessWndProcException.
Außerdem macht es in meinen Augen keinerlei Sinn aus der UI heraus in eine tiefer UI Schicht eine Exception zu werfen.
Technisch solltest Du in der UI in jedem Handler alle auftretenden Exceptions auch behandeln.
-
Dem würde ich gerne Folge leisten, ich finde meine Fehler aber nicht, wenn das Programm nicht abstürzt, wenn es sollte. Bei einem catch(...)-Block stellen sich mir alle Nackenhaare auf. Es gibt Exceptions, mit denen kann ich was machen, bei allen anderen hat das Programm sich möglichst schnell zu verflüchtigen.
Das ist einfach scheiße so, wie es nunmal gerade ist. Wenn eine exception fliegt, nicht behandelt wird und das Programm trotzdem weiterläuft, dann läuft etwas gewaltig schief. Da ist es mir auch egal, ob noch OS-Code dazwischen liegt oder nicht oder was es noch für andere ausflüchte gibt. Dann muss Windows meinetwegen neu programmiert werden oder Visual C++/MFC mit Exceptions anders umgehen.Soll ich jetzt ProcessWndProcException überschreiben und ein TerminateProcess reinklatschen, oder wie ist das gedacht?
-
Also CExpections führen normalerweise auch zu einem Fehler.
Schau Dir mal die normale Behandlung an in der MFC. Ich habe die aktuell nicht im Kopf.Ich wüsste nicht, wann solch eine Exception zum Weiterlaufen des Programmes führt. Normalerweise führen die zu einer Anzeige und das wars, bestimmte Exception terminieren auch das Programm. Wenn C++ Exceptions geworfen werden crashed normalerweise die Anwendung.
Um was für Exceptions geht es eigentlich?
-
Boost, meine eigenen, access violations. In einem WinApi-Programm findet halt so ziemlich alles in einem Message-Handler statt, mal von den unabhängigen Workerthreads abgesehen. Und der WM_COMMAND-Handler scheint ganz besodenders gerne exceptions zu schlucken.
Ich habe mein Programm jetzt einmal mit einem Windows7-Manifest versehen (hoffentlich habe ich das überhaupt richtig gemacht). Mal sehen ob das was hilft. Ist halt x86-Code auf Win 7 x64...
-
Manifeste spielen hier keine Rolle!
