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

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

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

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

-Dave