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

From: carlos pizano (carlospizano_at_[hidden])
Date: 2003-09-24 00:28:37

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

Sure. I thought that failing the test would end the app. I agree it
should end the current test process w/ no dialogs or further user input.

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

Mmm... which part? The stack unwinding part (after the crash log) could
be good idea if the code was done with RAII for persistent resources
such as files, databases, external hardware, etc. I guess it could
depend in the nature of the error and the things are actually done when
the nested objects in the stack are destroyed.

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

Yeah I wrote that before seeing your post of 9/23. I think there is an
error w/ the use of the translator.

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

Well, what I am talking about is not much more complicated to what you
have today in boost.test. In terms of runtime resource expenses seems
just about par too. If you check the current execution_monitor code for
Borland + Windows you actually have something of this nature already
there.

Also note that if that SE translator code is removed from the current
code, more the need to change other things around anyway.

> It certainly doesn't do any favors for testers and developers,
> the primary audience of Boost.Test.

I'll come up with a more flesh out pseudo code. Then we will evaluate if
it leaves them worse or better and at what cost. 

CPU

-----Original Message-----
From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]] On Behalf Of David Abrahams
Sent: Tuesday, September 23, 2003 4:49 AM
To: boost_at_[hidden]
Subject: [boost] Re: boost::execution_monitor impl under windows

"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
_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost