From: terekhov (terekhov_at_[hidden])
Date: 2002-01-14 22:09:56
--- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
> The point of all this is that it doesn't matter if the operation
> ReallyReallyBad or any other exception, including ones whose name
> know: the recovery action is always the same, and is based on the
> operation's exception guarantee. <language-bashing>That's why
> on always knowing the exception types at the expense of
> happened to the program state is so wrongheaded</language-bashing>,
> <opinion>why compiler-enforced exception-specifications are not
> good idea that they seem to be at first</opinion>.
> Yes, it's possible to design degenerate operations which break this
> but there aren't too many of these around, even in legacy code. The
> basic/strong/nothrow guarantees encourages a cooperative model
> degenerate cases are even less likely.
Thanks for the write-up! However, one more question.
I am just concerned that our "plug-in" operation
might have some programming error in it, which
would manifest itself with some "unexpected"
exception and broken safety guarantee. I just want
to use "unexpected" as an indication whether I am
still running in "secure" environment. Is this a
totally silly idea? Please explain why.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk