[boost] Re: Re: Re: Re: Attempting resolution of Threads&ExceptionsIssue

From: Hillel Y. Sims (hsims_at_[hidden])
Date: 2002-08-13 17:05:44

"David Abrahams" <dave_at_[hidden]> wrote in message
news:0bab01c2430b$bc5fa040$6501a8c0_at_boostconsulting.com...
> I think your statement is too sweeping.

Thank you for your straightforward response. Below, I hope to still try to
convince you (and everyone else) otherwise. :-)

> It's a good guideline if:
>
> 1. You have to cope with systems that integrate "crash" exceptions with
C++
> EH

Such as Windows (or portable code that intends to be compatible with
Windows)?

> 2. They don't provide a workaround, like the ability to handle the "crash"
> at the site of detection

Such workarounds are inherently non-portable, even if/when they do exist.

> 3. You hope to recover from these crashes somehow or debugging
requirements
> mean you have no alternative

Or just not interfere with platform-specific hardware exception mechanisms
in portable user-code that has no understanding of such a thing.

>
> My rationale is:
>
> 1. We shouldn't advise every programmer to pick a coding style based on
> what some misguided implementations do

Fair enough, but on the other hand, what harm is there in a fully-portable
non-pessimizing workaround that generally helps to make software more
robust?

> 2. Single-base-class hierarchies are old-fashioned ;-)

I cede you this meaningless point on the basis of the ;-)... ;-)

> 3. We shouldn't encourage misguided implementations to propagate

Hey, if you can think of a good way to make Windows go away, please share
with the rest of us! ;-)

> 4. Your guideline doesn't always help, and it's too restrictive. The real
> problem is interaction with catch(...). Lots of stdlib implementations and
> existing code uses catch(...)
>

This is true, and is rather unfortunate, given the nature of catch(...). I
agree the whole thing (std::exception for true exception-safety) is kind of
fragile and relies on everyone along the chain conforming.

**However, we have seen a number of real-world examples of how catch(...) is
already completely unsafe on a variety of platforms anyhow (the most
important one being Windows, by virtue of its wide-ranging scope).** (google
links provided upon request for anyone who did not catch the prior
discussions in comp.lang.c++.moderated)

The only real solution to the problem of catch(...) being unsafe portably is
to explicitly separate hardware exceptions from software exceptions. You
have claimed this can be accomplished on Windows via a non-portable
mechanism (though it has not been established that even that is 100%
effective) (is that workaround used in boost code?), but I assert that it is
not even possible currently on several other platforms (well maybe many of
you don't use VMS, but a lot of people do). Perhaps it would be possible to
make this forced separation explicit in the standard itself in the future
(it would likely be the only way to make exception-handling portably safe
while avoiding the universal use of std::exception as the base class)?
However, in the meantime, it is fairly easy for portable user-code to
enforce this explicit separation by simply adhering to use of std::exception
as the ultimate base class of user-defined exceptions. In my opinion, this
is really just another aspect of exception-safety for code to aspire to
achieve.

thanks,
hys

--
Hillel Y. Sims
FactSet Research Systems
hsims AT factset.com