|
Boost : |
From: Reid Sweatman (borderland_at_[hidden])
Date: 2000-08-13 10:05:23
> -----Original Message-----
> From: David Abrahams [mailto:abrahams_at_[hidden]]
> Sent: Sunday, August 13, 2000 6:55 AM
> To: boost_at_[hidden]
> Subject: Re: [boost] Exception usage (was: Threads by Jeremy and
> Monitors in one?)
> > Yes, a broken precondition
> > should be fatal, whereas a class-invariant problem may not be.
>
> Er, how so? If a class invariant is broken, the precondition to any of its
> member functions is broken, too.
Depending on just what the broken invariant is, it may be possible to fix it
before it matters, probably by letting the invariant test try to patch it
up. It would depend on whether or not the information necessary to do the
repair is available locally.
> Only Stroustrup's very latest printing of C++PL 3rd edition contains his
> latest writing on exceptions. But you can also find it online at
> http://www.research.att.com/~bs/3rd_safe0.html. I think there are still a
> couple of errors in there so you can pick up an "editor's bounty" if you
> read carefully ;)
I bought it when it first came out, so thanks for the URL.
> That's a different question altogether. I'm one of those people
> who jumps up
> and down about how dangerous exception-specifications are. My
> advice is: go
> ahead and use exception-handling, but stay away from
> exception-specifications unless you've thought very hard about the
> consequences. Then think again before you use them.
That's why I asked a while back. I had gathered that compiler
non-optimizations made empty throw specifications a generally bad idea at
the present, but still thought of non-empty ones as sort of necessary for
controlling unexpected exceptions. Probably because every book I've read on
exceptions has treated try/throw/catch and decorations as a package. I
didn't at first realize you don't have to use decorations. And in light of
the maintenance problems as the codebase grows, I think you've got me
leaning towards not using them. Fortunately, I'm early enough into my
current project that it won't be a revisitation of the Spanish Inquisition
to make that change.
Reid Sweatman
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk