From: carlos pizano (carlospizano_at_[hidden])
Date: 2003-09-21 18:57:11
> URL please.
> 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?
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
> 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.
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?
> Interesting things are counter-productive at this point.
Okeey.. How should I read that?
> "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
>> Think about it.
> No thanks! ;-)
I know, thinking sometimes is difficult. I hope I can get the attention
of the maintainer of boost.test and that he/she feels like thinking.
[mailto:boost-bounces_at_[hidden]] On Behalf Of David Abrahams
Sent: Sunday, September 21, 2003 1:16 PM
Subject: [boost] Re: boost::execution_monitor impl under windows
"carlos pizano" <carlospizano_at_[hidden]> writes:
> Dave Abrahams wrote:
>> No, I'm disabling the warning with pragmas. The technique works
> I don't think so. Well, it can fail.
It only fails under restricted circumstances, which are documented.
> See Carl Daniel post on 9/21.
> I saw the thread(s) on comp.lang.c++.moderated about the subject but
> nobody mentioned the interaction of the *technique* with /EHs at
> that time.
> Here is where I am going with this. The current way, complied with
> seems to me that can be better done with something along the lines of:
> catch( specific_type1& )
> catch( specific_type2& )
> ... other type specific catch(s) here..
> ... do not put catch(...) here ever..
> __except ( filter(GetExceptionInformation()) )
> } // end of function
> /* take the above code at the pseudo-code level */
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.
> Now, inside filter() you can do interesting things for instance
> re-throwing the SE under certain conditions or checking for the magic
> number that says that the SE is really a C++ exception and maybe do
Interesting things are counter-productive at this point. "Invoke the
debugger" is the right thing to do for developers, and "report
failure and terminate" is the right thing to do for testers.
> Note that the code above will be done in two nested calls since VC
> does not Allow you to mix __try and try on the same function.
> There seems to be very little restrictions on what filter() can be,
> I wonder if we can make it dispatch to a virtual function so a
> derived class can customize the behaviors.
> Think about it.
No thanks! ;-)
-- Dave Abrahams Boost Consulting www.boost-consulting.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk