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

From: carlos pizano (carlospizano_at_[hidden])
Date: 2003-09-22 22:32:35

> 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. The hope is to actually contribute, not to
annoy people asking stuff that was already said.

The execution_monitor and family seem a useful facility. I can see three
phases where it can be useful:

1- Development
2- Testing
3- Release (field deployment)

The overall goal is to *manage* exception and native signals that are
not normally handled by the code. Now, what you want depends on what
phase are you working:

For development, the goal now I gather more clearly is to prevent stack
unwinding and break into the debugger asap. Make it easy for the
developer to pinpoint the origin, causes and state when the exception
occurred. I believe that is what David A. technique (translator-rethrow
+ /EHs) is used for. Here my recommendation is to put a note on the
source because otherwise looks like a mistake, especially when the
compile settings use /EHs.

For testing I think that the goal is not JIT debugging but log the error
& fail the test. Maybe stack unwinding is ok. 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.

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.
Optionally some people would want to attempt to restart the application.

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

> If catch_system_error is on execution_monitor
> installs translator that reports an error and throws an special
exception
> signalling fatal error. Boost.Test translates this exception and
invokes
> fatal error procedures (main part is to show a test results report).

Well, here I go again. Isn't it an error with /EHs to throw this
especial exception from the translator? I mean, the re-throw is fine
since there no intention to catch anything but to do JIT. Here you are
actually expecting to catch this exception downstream and report...
right?

CPU

-----Original Message-----
From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]] On Behalf Of Rozental, Gennadiy
Sent: Monday, September 22, 2003 7:59 AM
To: 'boost_at_[hidden] '
Subject: RE: [boost] boost::execution_monitor impl under windows

> Hello Boosters. I am looking into the boost.test library for insights.
> In particular I like the boost::execution_monitor idea. However, I
found
> that on Windows + VC execution_monitor implementation uses
> _set_se_translator() to translate native exceptions (SEHs) into C++
> exceptions

It was discussed couple times in the list; you may found interesting
information in search. Here approximately how it stands now:

execution_monitor::execute has a parameter catch_system_error. If
catch_system_error is off execution_monitor installs translator that is
using the technique described in Dave A. article (and catch(...) later
on in
the code does not intersept). If catch_system_error is on
execution_monitor
installs translator that reports an error and throws an special
exception
signalling fatal error. Boost.Test translates this exception and invokes
fatal error procedures (main part is to show a test results report).

> I hope that execution_monitor could be used beyond (unit) testing.

It was intended this way.

Gennadiy.
_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost