[boost] std::exception -- Re: Re: Re: Re: Re: Attempting resolutionofThreads&ExceptionsIssue

From: Hillel Y. Sims (hsims_at_[hidden])
Date: 2002-08-13 20:48:48

"David Abrahams" <dave_at_[hidden]> wrote in message
news:0c4f01c2431d$f2481cc0$6501a8c0_at_boostconsulting.com...
> From: "Hillel Y. Sims" <hsims_at_[hidden]>
>
>
> > "David Abrahams" <dave_at_[hidden]> wrote in message
> > news:0bab01c2430b$bc5fa040$6501a8c0_at_boostconsulting.com...
> > > 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.

The std::exception-based solution is 100% portable. :-)

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

Sure. How about silently corrupting important data (possibly with billions
of dollars or human lives depending on it)?

I just thought of another one:
4. The standard library already throws exceptions inherited from
std::exception, and you don't want to introduce another completely
orthogonal hierarchy just for the sake of being contrary.

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

When you define custom exception hierarchies (non std::exception-based), do
you not already define virtual destructors in your base class(es)? I really
don't see how this is a particularly relevant concern, except in the most
extreme cases (maybe embedded systems with limited memory, but then the
software is probably not intended to be very portable anyhow). What other
costs are you referring to -- a few inherited exception-specs slowing down
that otherwise super-speedy exception throwing mechanism?

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

I think I've found one -- inherit all exception objects from std::exception.
That leads to being able to avoid the questionable (at the least) catch(...)
construct. :-)

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

Hmm, I'm sure it's their top priority issue.. how soon do you think until it
is fixed?

> 'Course, there are downsides, too.

Such as???

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

Really? -->

> catch(...) is far from "completely unsafe" on Windows,
> especially if you use my _set_se_translator workaround.
[..]
> 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.
[..]
> That's not the hack I'd use if I had a choice.

>Whether it's unsafe
> on other platforms depends on the platform, your needs, and what
> workarounds are available.

I find std::exception to be a nice portable technique that works on all
platforms. :-)

> I would hope VMS et al have
> a continuation-model mechanism for handling hardware problems at the site.

(It is very rare that you would want to continue execution after a hardware
exception..! But yes, VMS does have such a mechanism. Actually the Windows
NT-based native exception handling is pretty much derived from the VMS
exception handling system, and is quite similar in usage. Although VMS is
better. ;-)

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

How do you figure that inheriting from std::exception (which is both
standard and clearly designed to be a base class of _some_ sort, what with
the virtual destructor and all) is a hack?

I see two pieces to the whole thing:

1) Inherit exception objects from std::exception -- I cannot see any real
downside to this suggestion in portable libraries such as boost (especially
something like boost -- actually boost.regex already follows this, not sure
about any other boost libs). This provides maximal portability and
flexibility for end-users. If this is not already a boost guideline, I would
strongly recommend its adoption as such.

2) Avoid catch(...) -- here you can make the case that this is not suitable
for a portable library such as boost, and perhaps there I will concede to
you this argument slightly, since not everyone uses std::exception-based
exceptions and not all platforms are affected. At least boost is open source
so I can change those unfortunate catch(...) to the superior
catch(std::exception&) form on my system. RAII-based cleanup is usually
superior to either construct anyhow, as cleanup can be totally dependent on
whether the exception is handled at an ultimate end-point or not, which
generally leads to debugging goodness, if nothing else. The end result is
that code that makes use of catch(...) is simply not 100% safe on various
platforms at the present time (including Windows), whether anyone likes it
or not. Maybe it's 99.44% "good enough" for most Windows software, and the
remaining 0.66% will be fixed "someday", but my applications are part of a
system that is responsible for billions of dollars of financial decision
making every day, and though I am quite far from being a programming master
who has no bugs in any of my code, I prefer to avoid the use of constructs
which can provably inherently lead to silent data corruption.

Anyhow, we really started out this particular thread just discussing the
merits of #1, which I really don't think is anywhere near as contentious as
#2...

Thanks if you made it this far,
hys

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