Boost logo

Boost :

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
    many applications."

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

Or, hopefully, from other places not involving exceptions...


Boost list run by bdawes at, gregod at, cpdaniel at, john at