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

From: David Abrahams (dave_at_[hidden])
Date: 2003-09-23 05:49:15

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

>> Could you, please, explain again what and how you propose to enhance.
>
> Yes. I should. There are several issues that are intertwined.
>
> First off, I think the answers to my original post have all been good.
> As usual, quite cryptic. 

I think that's unfair.  I went to some effort to be very clear.

<snip>

> For testing I think that the goal is not JIT debugging but log the error
> & fail the test. Maybe stack unwinding is ok. 

I think it's a big "maybe".  Someone should prove why "log the error
and exit immediately" isn't a better answer, since, if the test
crashed, the system is in an unpredictable state, and even if testing
that executable continues, the result of executing future tests is at
best unreliable.

> I am not clear here but I assume that tests are meant to be run
> unattended so you do not want crash dialogs to popup and hold other
> tests.

Sure, but "exit immediately" doesn't imply a crash dialog.

> For release I think the goal can be similar to the test scenario but
> much more info needs to be logged to a file so that a customer can send
> it to support. I think stack unwinding is a good thing to do here.

Why?  Please justify that claim.

> Optionally some people would want to attempt to restart the application.

You don't need stack unwinding in order to do that.

> execution_monitor does not need to actually do all this but enable
> any of this scenarios (and possibly more) for derived classes.
>
> All this scenarios assume a) that the user code does not have the
> dreaded catch(...) and b) that the two basic types of errors are
> native signals such as structured exceptions or C++ exceptions that
> are not catched in user code.
>
> In a previous post on this same thread I proposed a pseudo-code
> skeleton to try to accomplish some of this and to try to correct the
> translator-rethrow + /EHs error. Now, according to the other posters
> there is no error there 

I am not claiming there's no error in the existing test library's use
of EH.

> and second my pseudo-code can do unwinding if there is a
> catch(...){throw;} so that my code needs to be modified/refined.
>
> I am currently doing experiments to see what would be a good solution.
> Unfortunately this would be only applicable to windows since the
> solution I have in mind is a careful combination of __try/__except and
> try/catch blocks and I have no clue about how to extend this to other
> OSes.
>
> One way is an outer __try/__except block and an inner try/catch block,
> the other more interesting one is the opposite case. 

Trying to unwind from SEHes just makes this whole thing way more
complicated than it should be, and I'm not convinced it's worth the
cost.  It certainly doesn't do any favors for testers and developers,
the primary audience of Boost.Test.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com