Re: [boost] Re: boost::execution_monitor impl under windows

From: Peter Dimov (pdimov_at_[hidden])
Date: 2003-10-08 15:22:38

Alexander Terekhov wrote:
> Peter Dimov wrote:
> [...]
>> Consider:
>>
>> void f() throw(X); // calls g
>> void g() throw(Y); // calls h
>> void h() throw(Z); // throws Z();
>>
>> The Z exception hits the throw(Y) wall; unexpected() eats the Z and
>> throws Y.
>
> Only if there was no other unexpected handler active by the time
> something inside h() throws Z. And, BTW, by the time Z hits the
> throw(Y) wall, your RAII object that sets/resets g()'s unexpected
> handler is absolutely gone; dead completely. What's left is just
> a silly pointer that was saved at Z's throw point... hmmm, and
> what about "some associated resources", if any?

Yes, that's correct. I am assuming a single unexpected() handler here.

>> Y hits throw(X), unexpected() now throws a X.
>>
>> If you invoke unexpected() before the unwinding, there is no way you
>> can get an exception to escape through the three ex.specs.
>
> Why not simply catch Z/throw Y in g() and catch Y/throw X in f()?
>
> No brainer, oder?

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.