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

From: Hendrik Schober (boost_at_[hidden])
Date: 2002-06-20 06:12:32

"David Abrahams" <david.abrahams_at_[hidden]> wrote:
> [...]
> >   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?

  Mhmm. I understand that Unix core dumps provide this 
  "post mortem". Since the platform I work on doesn't 
  have this, for me so far there were two possibilities: 

  Either I'm debugging the app, then I always have a 
  breakpoint in my exception base class' ctor and can 
  see the stack with all local variables etc. from it.
 
  Or the app is running at a customers. Then, for the 
  reasons given earlier, I usually want to avoid to have 
  my code abort. Then, my (intrusively) collected 
  exception stack info, together with the logging output, 
  is a really great improvement over an "abnormal program 
  termination" message, which my system gives me. 

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

  I don't think it is more useful for the customer, 
  since are core dump usually also means that they 
  lost their work. 
  As I've said before, customers calling in because 
  they've lost hours of work when the printer driver 
  blew it while they were doing a test print will 
  not raise my reputation in the support department. 

> [...]
> > > 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.

  That seems to be a misunderstanding. I don't think 
  exception should be thrown merely to get a call stack. 
  But I thought we were discussing the usefulness of 
  intrusive/non-intrusive stack tracing in the case of 
  an exception. 

  Well, of course, once you have a portable/ported way 
  to get a call stack from any point of the program, 
  using this in the exceptions ctor would make a lot of 
  sense. I just never attempted to do this even across 
  the few platforms we program for. 

> -Dave

  Schobi