Boost logo

Boost :

Subject: Re: [boost] [thread] thread_proxy's catch(...) destroys my stack info for unhandled exceptions
From: Dmitry Goncharov (dgoncharov_at_[hidden])
Date: 2008-12-29 02:35:38

Roberto Gimenez wrote:
> Dmitry Goncharov <dgoncharov <at>> writes:
>> Your f1() and f2() are callback function. If such a callback function
>> throws an exception the program should be terminated, since the os
>> cannot handle the exception for you.
>> That's reasonable to embrace callbacks like f1() with a catch all block
>> and deal with the exception the way you want.
>> E.g.
>> void f1()
>> {
>> try { throw 1; }
>> catch(...) {abort();} // Here is your core dump.
>> }
>> If everybody did that there would be no need for boost::thread to
>> provide the catch all block.
> If everybody did that then everybody would lose their stack info and won't
> know where the unexpected exception occurred. Unfortunatelly where
> this doesn't happen the try-catch(...)-terminate() is a better option, but
> where this does happen then it is not. So I guess a macro flag or bool flag
> whould be good, or directly relying on the programer to put the try-catch(...)
> inside the callback if needed.
On linux you can save your call stack in an exception object and read it
in a catch block.
Have a look at execinfo.h (usually /usr/include/execinfo.h). backtrace()
is to obtain the backtrace.
backtrace_symbols() is to get the function names of the addresses
returned by backtrace().
backtrace_symbols() returns manged names, so you'll want to demangle the
names with __cxa_demangle() (from cxxabi.h).

Br, Dmitry

Boost list run by bdawes at, gregod at, cpdaniel at, john at