Boost.Exception : Nicht fangbare Exception?



  • Hoi 🙂

    Habe hier ein doofes Problem. Erstmal der Code:

    try
    {
      auto proc = getProcessByName("kcalc");
      if(!proc)
      {
        cout << "KCalc is not running !" << endl;
        return -1;
      }
    
      Debugger debugger(*proc);
      debugger.attach();
    }
    catch(EthonError const& e)
    {
      cout << "Exception occured in " << *boost::get_error_info<ErrorFunction>(e) << endl;
      cout << "Description: " << *boost::get_error_info<ErrorString>(e) << endl;
    
      std::error_code const * const errorCode= boost::get_error_info<ErrorCode>(e);
      if(errorCode)
      {
        cout << "Errorcode: " << *errorCode << endl;
      }
    }
    catch(...)
    {
      cout << "Unexpected Error!\n" << endl;
    }
    

    Ja, hier werden überwiegend "meine" Klassen verwendet.
    Sollte allerdings vom Prinzip her keinen Unterschied machen.
    Ansonsten, hier wäre der Code: http://code.google.com/p/ethonmem/source/browse/#svn%2Ftrunk

    Trotzdem bekomme ich bei der Debug-Version immer diesen Output:

    terminate called after throwing an instance of 'boost::exception_detail::clone_implEthon::EthonError'
    what(): std::exception
    Aborted

    Die Exception fliegt, soweit ich per Breakpoints nachvollziehen konnte, bei Debugger::attach. Diese Funktion läuft im selben Thread und macht nichts außer eine Systemfunktion aufzurufen und bei Fehler eine Exception vom Typ EthonError (erbt virtuell von boost::exception und std::exception) zu werfen. Die sollte doch auf jeden Fall gefangen werden?

    Kann mir das bitte jemand erklären? Danke! 🙂
    Grüße,
    Ethon



  • Evtl mal nen Project Rebuild?



  • Hi.

    Schon viele Male geschehen, bringt nichts 😕

    Grüße,
    Flo



  • Hats du mal tiefer rein debuggt? Wird da evtl. irgendwo eine zweite Exception geworfen, während schon eine aktiv ist?



  • Nicht debuggt, aber während dem Duschen hab ich über die Sache nachgedacht ... der Destruktor hat gleich noch eine Exception nachgeworfen. Da lag der Fehler. 🙂

    Etwas Offtopic, aber kanns sein dass eine Dusche besser ist als jeder Debugger? Ich finde die Lösungen für Probleme am Besten beim Duschen 😃



  • Destruktoren dürfen nie Exceptions werfen, sonst ist die Hölle los.

    Aber ja, auch mir fallen viele Dinge (besonders Designsachen) ein, wenn ich nicht vor dem Computer sitze... 🙂



  • Mein Destruktor muss aber eine potentiell werfende Funktion aufrufen.
    Wäre ein try-catch-Block innerhalb des Destruktors ok?



  • Wäre ein try-catch-Block innerhalb des Destruktors ok?

    Ja, nur du musst dir überlegen wie du die Exception innerhalb des Destruktors richtig behandelst. Nur verlassen darf sie den Destruktor nicht.



  • Ja, sofern keine Exception den Destruktor verlässt. Ist dann halt nicht immer trivial, eine Fehlerbehandlung durchzuführen...

    Aber nicht-werfende Destruktoren und Deallokationsfunktionen sind ein Grundbaustein für eine exceptionsichere Anwendung, weil man sich ohne sie auf gar nichts mehr verlassen kann. Mindestens die Basis-Garantie (konsistente Zustände, doch Rollback nicht immer möglich) sollte angestrebt werden.



  • Ethon schrieb:

    Mein Destruktor muss aber eine potentiell werfende Funktion aufrufen.
    Wäre ein try-catch-Block innerhalb des Destruktors ok?

    Ja, solang der catch alles fängt was fliegen kann und selbst nicht wirft.

    Siehe auch hier:
    http://www.gotw.ca/gotw/047.htm

    und hier:
    http://www.gotw.ca/gotw/066.htm


Anmelden zum Antworten