try catch Problem, Nur throw geht...
-
Unter VC6 hat catch(...) beide Typen von Exceptions gefangen, obwohl das nicht so gedacht war.
Eine SEH Exception darf IMHO einfach nicht auftreten!
Es gibt schon Situaitonen, in denen man mit SEH's rechnen muß - z.B. Memory Mapped Files oder Read/WriteProcessMemory.
-
peterchen schrieb:
Es gibt schon Situaitonen, in denen man mit SEH's rechnen muß - z.B. Memory Mapped Files oder Read/WriteProcessMemory.
Und warum muss ich damit rechnen? Schon ganz und gar bei Memory Mapped files? IMHO mache ich was falsch wenn sowas auftritt und man kann verhindern durch entsprechende im Vorfeld Tests, dass diese auftreten.
Ich arbeite sehr viel mit Memory Mapped Files aber einen SEH Handler habe ich niergends drin aus einen Default Exception Handler der mir Minidumps erzeugt im Falle eines Crashs!
-
@Martin: bei Memory Mapped Files kanns dir halt passieren dass, sobald jemand z.B. eine Festplatte absteckt, ein File nichtmehr da ist, und daher lustige Access-Violation Exceptions fliegen wenn man versucht auf den entsprechenden Speicherbereich zuzugreifen. Das ist dann nicht unbedingt ein Programmfehler. Obwohl man darüber streiten kann ob es nicht überhaupt ein Fehler ist eine Datei Memory Mapped aufzumachen von deren "unerwarteter Abreise" sich das Programm "erholen" könnte.
-
MMF's können auch (IIRC) mit FILE_SHARE_DELETE geöffnet werden - Bumm!
SetFilePos(0,FILE_BEGIN); SetEndOfFile();- Bumm!
Ein SEH macht da den Unterschied zwischen Ist mir viehischst um die Ohren geflogen und Da kam so 'ne Meldung, irgendwas mit "Tun sie das nie wieder!". Ob sich das lohnt, liegt an der Anwendung.
-
Es sei, mal wieder, angemerkt, dass ab VS2005 einige "Exceptions" nicht mehr an das Programm weitergeleitet werden, sondern *hart* an das OS übergeben werden!!!
-
peterchen schrieb:
Ein SEH macht da den Unterschied zwischen Ist mir viehischst um die Ohren geflogen und Da kam so 'ne Meldung, irgendwas mit "Tun sie das nie wieder!". Ob sich das lohnt, liegt an der Anwendung.
Beziehungsweise an den Anforderungen, die an die Anwendung gestellt werden. In manchen Bereichen (WinXp embedded zum Beispiel) muss man mit solchen etwas bösen Fehlerfällen aufgrund einiger Randbedingungen rechnen und ggfs. korrekt weiter arbeiten. Ist zwar nicht schön, aber muß ja :-).
Gruß Kimmi
-
Dem kann ich nicht zustimmen, siehe:
http://blogs.msdn.com/david_leblanc/archive/2007/04/03/exception-handlers-are-baaad.aspx
-
@Matrin:
Ich denke, man sollte unterscheiden, was man fängt und wie man damit umgeht. Soll zum Beispiel ein MiniDump bei einer Win32-Excpetion geschrieben werden, macht das Fangen Sinn (wie du ja auch schon zuvor sagtest).
Soll der Prozess aufgrund einer Win32-Expection zumindest andere Prozesse benachrichtigen: Ich bin kaputt, trau mir nicht mehr, kann dadurch ein falsches Weiterarbeiten verhindern und ggfs. den Prozess mit dem Problem neu starten.Gruß Kimmi
-
Dazu brauch man aber kein __try, das geht mit SetUnhandledExceptionFilter viel schöner/besser/bunter/preiswerter/sicherer/... . Siehe auch Jochens Beitrag (sein Artikel erklärt auch die Fallstricke die MS in neueren Compiler-Versionen bezüglich SetUnhandledExceptionFilter eingebaut hat).
-
Hm, stimmt. Hatte da was gerade falsch in Erinnerung. Musste noch mal nachlesen und nehme Abstand von __try :-).
Gruß Kimmi
