Re: [boost] Re: Re: Re: improved assertions?

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
confusing.

>   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
stack
> > leading to the allocation. If every allocation causes an exception,
your
> > 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.

-Dave