Boost logo

Boost :

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-06-19 07:15:59

From: "Hendrik Schober" <boost_at_[hidden]>

> > Exceptions cause unwinding. Often you don't want that.
> >
> > Example 1: assertions. By the time the stack is unwound much
information is
> > lost.
> You can capture the stack in the exception's ctor.

...and the values of all local variables, in a useful way? What about the
state of objects whose destructors run during unwinding?

> > On Unix, for example, you want a core dump, not an exception.
> I didn't do much Unix programming, but I commonly
> don't want my apps to core dump at a customer's.

You don't want it to assert either. The information in a core dump is more
useful to you and the customer than a call stack description, and no more

> What I noticed is, using VC6, you can actually
> catch SEH's using the 'catch(...)' notation. If
> you re-throw the exception using 'throw', and
> it's not "swallowed" somewhere further up in the
> call stack, the debugger will still refer you to
> the line where the AV actually happened.
> That seems strange, but I actually make use of it
> in my framework.

I use that technique all the time. However, it doesn't work if the SEH
occurs from within a catch block.

> > Example 2: memory allocation tracking and leak detection. An extremely
> > useful technique involves labeling each allocated block with the call
> > leading to the allocation. If every allocation causes an exception,
> > program won't get far.
> You mean, "if every allocation causes an exception
> instead of a core dump"? Why is that a problem if
> you can get the stack from the exception's ctor?

No, I mean that allocation requests are supposed to return a memory block
unless memory is exhausted. If you have to throw an exception to get the
stack trace, you can't return the memory block.


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