|
Boost : |
From: Peter Dimov (pdimov_at_[hidden])
Date: 2003-10-08 16:21:23
Alexander Terekhov wrote:
> Peter Dimov wrote:
> [...]
>> Keep in mind that I think that exceptions specifications are
>> "totally brain damaged"; I'm just trying to reconstruct their design
>> rationale. The idea is, I think, that these three functions are part
>> of three different subsystems, libX, libY, libZ. Each has its own
>> exception type, and doesn't know or care about the others. Or
>> something. There is a central exception translator in unexpected()
>> that maps Z to Y and Y to X, so the functions themselves don't need
>> to do that.
>
> Won't work if both libX and libY can "share" (call directly) libZ.
I know. It doesn't matter. The point is that exception specification
violations apparently unwind _by design_. It's hard to change something in
the standard that is not a defect.
> As for reconstructing design rationale, my take on this can be found
> here:
>
> http://groups.google.com/groups?selm=3F78478A.F0CCBD0%40web.de
> (Subject: Re: Catching access violation exceptions [OT])
"EH as defined by the current standard is pretty much broken and
is nothing but a compromise influenced by "rumors" that <quote>
On other systems, it is architecturally close to impossible not
to invoke the destructors while searching for a handler </quote>
(Pg. 381, TC++PL [my pdf version])"
That's true for the implementation-defined unwind but not for violated
exception specs. I've always found it odd that main() is not throw(), but
apparently this is intentional.
I'm not saying that this is a good idea. I'm saying that it would be very
hard to change it.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk