Boost logo

Boost :

From: Hendrik Schober (boost_at_[hidden])
Date: 2002-06-19 03:46:16

"David Abrahams" <david.abrahams_at_[hidden]> wrote:
> [...]
> ----- Original Message -----
> From: "Fernando Cacciola" <fcacciola_at_[hidden]>
> > ----- Original Message -----
> > From: "David Abrahams" <david.abrahams_at_[hidden]>
> > > 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.
> > >
> > > -Dave
> > >
> > I don't understand what you mean. Could you elaborate it?
> Exceptions cause unwinding. Often you don't want that.
> Example 1: assertions. By the time the stack is unwound much information is
> lost.

  You can capture the stack in the exception's ctor.

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

> On
> Windows you also don't want stack unwinding, though the case is a little
> more complicated there.

  What I noticed is, using VC6, you can actually
  catch SEH's using the 'catch(...)' notation. If
  you re-throw the exception using 'throw', and
  it's not "swallowed" somewhere further up in the
  call stack, the debugger will still refer you to
  the line where the AV actually happened.
  That seems strange, but I actually make use of it
  in my framework.

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

> -Dave


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