Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2003-09-22 07:57:03

"carlos pizano" <carlospizano_at_[hidden]> writes:

>> URL please.
> Here:
>> What interaction?
> See URL above and/or Robbins book chapter 13
>>> I don't think so. Well, it can fail.
>>It only fails under restricted circumstances, which are documented.
> That is the *interaction* I am talking about: it can fail.
>> which are documented.
> Where is this documentation? In boost.test ? in the source?

In the article. Did you read it? I hope I don't need to provide the
link again.

> I would like to learn where it can and cannot work. My current
> understanding is that it works when the compiler does not optimize too
> much :)

No, it works unless the SEH is generated inside a catch block. As documented.

>> I think you are seriously missing my point. This is not a substitute
>> for my technique because it causes unwinding and recovery instead of
>> going immediately to JIT debugging.
> a) I guess I am. You mentioned earlier that you don't know what
> execution_monitor is doing, now is a good time to check it out because
> we are not talking about your technique in the vacuum.

I don't really care what it's currently doing. I'm saying that if
it's using my technique /EHa doesn't matter and if it's not using my
technique it probably should be.

> b) My proposal can do the same thing(s) as your technique for
> execution_monitor. Mine causes unwinding and yours not? You lost me
> there. Please explain.
> c) causes recovery? I never said recovery... where do you get that from
> my pseudo code?

OK, I mistoook the __except clause for a __catch. However, your code
differs from mine in one important way: if any inner code happens to

    catch(...) { ... throw; }

(which is still legitimate code on most platforms) it will still
produce unwinding.

>> Interesting things are counter-productive at this point.
> Okeey.. How should I read that?

I mean to say that the actions after an SEH should be very simple and
lead almost immediately to shutdown.

>> "Invoke the debugger" is the right thing to do for developers, and
>> "report failure and terminate" is the right thing to do for
>> testers.
> No problem there. Remember that we have other classes derived from
> execution_monitor where behavior is specialized for production or
> testing.

Not sure how that's relevant... but you can stick any code you like
before the "throw;" in my SE translator.

>>> Think about it.
>> No thanks! ;-)
> I know, thinking sometimes is difficult.

Yes, usually, in fact...

> I hope I can get the attention of the maintainer of boost.test and
> that he/she feels like thinking.

...but there's no need to patronize.

Dave Abrahams
Boost Consulting

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