Boost logo

Boost :

From: Alan.Griffiths_at_[hidden]
Date: 2003-10-02 02:56:19


> -----Original Message-----
> From: Alexander Terekhov [mailto:terekhov_at_[hidden]]
> Sent: 01 October 2003 19:33
>
> as I
> said, SEH exceptions are just ought to be "fully mapped" to the
> standard C++ exceptions.

That is a circular arguement - you are assuming the point you are trying to
establish. (One possible reason this mapping might not be possible is that
SEH does not respect sequence points.)

While C++ exceptions might reasonably be presented as a specialisation of
SEH exceptions the converse isn't true. (Aside from the unresolved question
over sequence points SEH exceptions can occur without a throw expression,
can be resumed, are not available on all platforms, ...)

>
> [...]
> > 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.
>
> ISO/IEC 14882:
>
> "If no matching handler is found in a program, the function
> terminate() is called; whether or not the stack is unwound
> before this call to terminate() is implementation-defined"
>

An implementation must document how it behaves and (admittedly only QOI)
some do it right. I prefer this to requiring them to do it wrong. In any
event this is not worth spending much time on - the program is broken.

-- 
Alan Griffiths
http://www.octopull.demon.co.uk/ 
------------------------------------------------------------------------
For more information about Barclays Capital, please
visit our web site at http://www.barcap.com.
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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk