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

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2002-06-19 10:16:34

----- Original Message -----
From: "David Abrahams" <david.abrahams_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Wednesday, June 19, 2002 9:15 AM
Subject: Re: [boost] Re: Re: Re: improved assertions?

>
> 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?
>
But can only get values of local variables and the state of objects before
unwinding from within a debugger right?
Then, why is it better to terminate the application than to throw an
exception? Borland, at least, stops execution at the throw expression, so
you can collect al the information you need and let the application keep
running.

>
> > >       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.
>
True, but it might be more useful to the customer not to collect any
information but keep to application alive. Of course this makes things more
difficult to the developer (unless some exception tracing and automatic
logging is used); but it might not be an option. In all our products, for
example, we just cannot terminate the application in the case of an error,
no matter how bad, so the best we can do is to collect and log as much
information as possible. This is supported -even if cumbersome- by the
exception model.

> >   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.
>
Yes, this show that the stack tracing and exception info collecting must be
implemented such that no exceptions are thrown by the process. (For example,
by using a static memory block as ring buffer)

Fernando Cacciola
Sierra s.r.l.
fcacciola_at_[hidden]
www.gosierra.com