Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2003-09-21 14:16:29


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

> Dave Abrahams wrote:
>> No, I'm disabling the warning with pragmas. The technique works fine.
>
> 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.

URL please.

> 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.

What interaction?

> Here is where I am going with this. The current way, complied with /EHs
> seems to me that can be better done with something along the lines of:
>
> execute()
> {
>
> __try
> {
> try
> {
> user_function();
> }
> catch( specific_type1& )
> {
> report1(text);
> }
> catch( specific_type2& )
> {
> report2(text);
> }
> ... other type specific catch(s) here..
>
> ... do not put catch(...) here ever..
> }
> __except ( filter(GetExceptionInformation()) )
> {
> report_def()
> }
>
> } // 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 your
> trick...

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

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk