Boost logo

Boost :

From: Alan.Griffiths_at_[hidden]
Date: 2003-10-01 10:14:52

> -----Original Message-----
> From: Alexander Terekhov [mailto:terekhov_at_[hidden]]
> Sent: 30 September 2003 10:17
> Raising SEH exception (or signal) is clearly a *side effect* (that
> isn't "covered" by the C/C++ standard...

If it isn't covered by the standard then the rules in the standard do not
cover it.

> > (And a quick search of MSDN doesn't return any promising
> hits.) Do you have
> > a reference?
> Nope. But I'd consider it simply "a bug" if they don't do it right.

You might consider it so - but that is subjective.

> (Subject: __attribute__((cleanup(function)) versus try/finally)
> (Subject: Exception handling... it's time to fix the standard)
> (Subject: std0X::expected_exception<T>())
> (Subject: Re: std0X::expected_exception<T>() [repost])

Lots of bits of arguement - hardly a clearly made case. What I get from
this is that you want a mechanism available at the throw site to determine
whether an exception will be handled. This mechanism could be used in two

  o by the programmer (who might decide to handle the error
    differently). I don't like code that depends on its
    environment in subtle ways - so this doesn't convince me.
    If, as a developer, that is what I want then I'd report
    the error using a callback.

  o by the runtime environment (which calls "unexpected"
    without *any* cleanup). While the program as a whole
    is clearly broken in this case, this breaks cleanup
    guarantees that exist between the throw point and the
    top of the stack. I prefer the existing behaviour.

In short, I don't understand what you are trying to achieve - and whatever
that might be you are introducing new problems for the developer.

Am I missing something blindingly obvious?

Alan Griffiths 
For more information about Barclays Capital, please
visit our web site at
Internet communications are not secure and therefore the Barclays 
Group does not accept legal responsibility for the contents of this 
message.  Although the Barclays Group operates anti-virus programmes, 
it does not accept responsibility for any damage whatsoever that is 
caused by viruses being passed.  Any views or opinions presented are 
solely those of the author and do not necessarily represent those of the 
Barclays Group.  Replies to this email may be monitored by the Barclays 
Group for operational or business reasons.

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