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