Re: [boost] Re: Re: Re: Re: Attempting resolution ofThreads&ExceptionsIssue

From: David Abrahams (dave_at_[hidden])
Date: 2002-08-13 18:05:35

From: "Hillel Y. Sims" <hsims_at_[hidden]>

> "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)?

Yes. Bear in mind, all three conditions must be true.

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

So what? The problem is non-portable too.

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

It's OK to evaluate whether that "interference" amounts to anything
important before deciding.

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

It may in fact be pessimizing for some applications. std::exception has a
few costs associated with it, most notably a vtable.

> > 2. Single-base-class hierarchies are old-fashioned ;-)
>
> I cede you this meaningless point on the basis of the ;-)... ;-)

Thanks!

> > 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! ;-)

I've spoken with VC developers who say they're looking for a good solution
to the problem. Having it be a problem that people complain about instead
of using a "workaround" which seems to make the problem go away encourages
them to keep looking. 'Course, there are downsides, too.

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

This is the only real problem I have with your argument: you persistently
overstate your case. catch(...) is far from "completely unsafe" on Windows,
especially if you use my _set_se_translator workaround. Whether it's unsafe
on other platforms depends on the platform, your needs, and what
workarounds are available.

>  (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)

Actually it has been established that it is not 100% effective: it doesn't
work when the program crashes from within a catch block. So what? It's
effective enough.

> (is that workaround used in boost code?),

Yes, all the Python library tests use it.

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

That's not the hack I'd use if I had a choice. I would hope VMS et al have
a continuation-model mechanism for handling hardware problems at the site.

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

IMO, this is just another platform-specific hack to be endured.

-Dave

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave_at_[hidden] * http://www.boost-consulting.com