Boost logo

Boost :

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2003-10-08 09:12:22

Peter Dimov wrote:
> My understanding of the two phase business is as follows:
> Phase 1: search for a handler;
> Phase 2: unwind to that handler and invoke it, but only if a handler was
> found.


> Extension: a function that performs phase 1 and returns a bool. No rationale
> (readily) available. Not sure whether, or why, this is a good idea.

I simply have some code (can't change the interface; too late) that
I'd like to kind "extend":

void operation() {
  bool cancel_expected =
    if (cancel_expected) std::test_thread_cancel();

The problem is that some clients have code that invokes it from throw()-
nothing places like d-tors... and don't {always} disable cancelation. ;-)

> This doesn't play well with exception specifications since,

Those are pretty much broken anyway.
(Subject: Re: Is internal catch-clause rethrow standard?)

> if I understand
> them correctly, (and I have no reason to, since I've never used one or seen
> one used,) a violated exception specification is required to unwind, _then_
> call unexpected(), which can then rethrow a different, "conforming",
> exception.

That needs some fixing, right. std::unexpected() shall be invoked at
throw point (as kinda "side effect" of throw-expression).

> It also implies that catch(...) should never, ever, be used with a rethrow
> as a "finally", since it deceives phase 1. I'm not sure whether this is
> going to work.

Yeah. Note that catch(...)/rethrow is totally broken "attached" exception
cleanup handler. Something like "action_on_propagation_of(...)" is the way
to go.


Boost list run by bdawes at, gregod at, cpdaniel at, john at