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

From: David Abrahams (dave_at_[hidden])
Date: 2003-09-26 16:18:47

Beman Dawes <bdawes_at_[hidden]> writes:

> At 08:40 AM 9/26/2003, David Abrahams wrote:
>
>  > ... discussion of SEH cases ...
>
> Let me try to summarize your points, to make sure I understand them:
>
> (1) Exceptions (and signals) from the operating system may come at
>     times when the C++ exception handling mechanism is unprepared to
>     unwind the stack. 

Not quite.  The EH mechanism may be perfectly prepared to unwind.
It's at a time when the _program_ is unprepared to have the stack
unwound.

>     For example, in a nothrow region such as a destructor.

Good example.

> (2) Because of (1), such operating system exceptions or signals should
>     not be trapped and converted to a C++ exception throw. To do so
>     risks serious failure.

Yes.  It also puts the handling of those conditions (cases of "the
program is broken; its invariants have been violated") on the same
execution path with conditions which can reasonably be recovered from
(e.g. "you couldn't get some resource you wanted").  That's also
dangerous because it's easy to lose track of the fact that the
condition is really unrecoverable once you fall into a catch handler.

> (3) It is useful, however, to call logging or stackdump facilities,
>     and then to terminate the program. ( But sometimes, such as during
>     interactive debugging

Or attended (not automated) testing.

>     trapping to the debugger would be the most useful action.
>
> Is that summary correct (although much simplified)?

Pretty close.

> It doesn't seem that (3) is always safe. The problem may have occurred
> in one of the logging or stackdump facilities themselves, for
> example. Calling them again might cause a loop. That could be
> protected against by a static "been_here_before" bool set the first
> time through. If it is true (the second time around), just terminate
> without any log/dump attempt.

That's a level of paranoia I haven't considered attaining.  I think I
would only want to set "been_here_before" in the fatal error handler,
not in the logging, since logging may be called for non-fatal
conditions.

> How should "terminate the program" be implemented? std::abort()?
> Remember that a major objective of catching the structured exception
> or signal in the first place was to ensure a non-zero return value
> from the program (rather than getting a dialog box or some other
> non-useful behavior).

Looking at my international standard, I'd say it's not quite clear.
terminate() might be a good choice, though there don't seem to be any
guantees about the exit code.  exit(EXIT_FAILURE) might be appropriate
for a program which reserves resources not reclaimed by the OS, such
as file locks on some systems, though I'd much rather handle that
stuff selectively and explicitly.  The standard doesn't mention dialog
boxes, so it's hard to say what abort() will do ;-)

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