From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-06-20 06:54:22
From: "Hendrik Schober" <boost_at_[hidden]>
> > > > 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
> > useful to you and the customer than a call stack description, and no
> > confusing.
> I don't think it is more useful for the customer,
> since are core dump usually also means that they
> lost their work.
assert() == abort() on failure
or at least, that's what I thought you meant.
I didn't realize you were trying to recover from a failed assertion.
Dangerous, but sometimes it's the only practical approach.
> > > 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
> > unless memory is exhausted. If you have to throw an exception to get
> > 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.
I was discussing the importance of having a stack tracing mechanism that
wasn't dependent on exceptions. As I said earlier,
"I just want to point out that the termination model used by C++
exceptions makes any approach using them unsuitable for a great
> 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
Or, hopefully, from other places not involving exceptions...
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk