4. try catch Problem, Nur throw geht...

try catch Problem, Nur throw geht...

  • 0

    Hallo,

    bislang war ich ja der Meinung, dass ein catch(...) alle Fehler abfängt.
    Jetzt hab ich hier ein VC++2005 MFC Projekt wo dem nicht mehr so ist.

    Bsp:

    void egal()
{
    try
    {
        test *t = NULL;
        t->aha = 0;
        //throw new CException(); //funktioniert
    }
    catch(...)
    {
        MessageBox....
    }
}

    Jetzt springt das Prog aber nicht mehr in den Catch-Block sondern crasht mit Windows Unhandled Exception MessageBox. Auch ein "Weiter", "Ignorieren" etc. bringt nichts. (Debug und Release versucht...JA) Hab ich da was verpasst, oder steh ich aufm Schlauch am Montag? Bei normalen C++ Anwednungen funktionierts ja auch noch.

    Gruß und Danke

    0
  • Mod

    Du irrst gewaltig. Solche harte Exceptions werden normalerweise nicht von try/catch abgefangen, sondern von __try/__catch

    Ausnahme /EHa! Aber von der Nutzung der Compiler Option /EHa kann man nur abraten.
    Zuviel Einfluss auf die Performance und ansonsten auch Unsinn:
    Eine SEH Exception darf IMHO einfach nicht auftreten! Das ist ein Bug und ein Programm gehört abgeschossen in dem Moment. Denn Du weißt in keiner Weise in wie weit Du wirklich solch einen extremen Fehler korrekt behandeln kannst.

    0
  • ?

    Eine SEH Exception darf IMHO einfach nicht auftreten! Das ist ein Bug und ein Programm gehört abgeschossen in dem Moment. Denn Du weißt in keiner Weise in wie weit Du wirklich solch einen extremen Fehler korrekt behandeln kannst.

    Da hast du vollkommen recht. 😃

    Aber:
    Ich bin aber der Meinung, das dass beim 6er Studio trotzdem immer funktioniert hat. Das /EHa Flag bringt irgendwie auch keine Abhilfe.

    0
  • P

    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.

    0
  • Mod

    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!

    0

  • @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.

    0
  • P

    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.

    0
  • J

    Es sei, mal wieder, angemerkt, dass ab VS2005 einige "Exceptions" nicht mehr an das Programm weitergeleitet werden, sondern *hart* an das OS übergeben werden!!!

    Siehe:
    http://blog.kalmbachnet.de/?postid=75

    0
  • K

    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

    0
  • Mod

    Dem kann ich nicht zustimmen, siehe:
    http://blogs.msdn.com/david_leblanc/archive/2007/04/03/exception-handlers-are-baaad.aspx

    0
  • K

    @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

    0

  • 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).

    0
  • K

    Hm, stimmt. Hatte da was gerade falsch in Erinnerung. Musste noch mal nachlesen und nehme Abstand von __try :-).

    Gruß Kimmi

    0
Anmelden zum Antworten