Re: [boost] std::exception -- Re: Re: Re: Re: Re: AttemptingresolutionofThreads&ExceptionsIssue

From: David Abrahams (dave_at_[hidden])
Date: 2002-08-13 22:07:43

From: "Hillel Y. Sims" <hsims_at_[hidden]>
> "David Abrahams" <dave_at_[hidden]> wrote in message
> > From: "Hillel Y. Sims" <hsims_at_[hidden]>
> > > > 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. :-)

Not to platforms whose std library uses catch(...).

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

How about it? If that was the consequence on a platform I cared about, I'd
find a way out. Maybe yours, maybe another.

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

Try me ;-)

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

Not neccessarily. Why bother? Are you planning to make a container of
polymorphic pointers to exception objects?

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

Sure, those are the ones.

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

Guessing? 3 years, off the cuff.

> > 'Course, there are downsides, too.
>
> Such as???

It's still a problem that people complain about.

> > This is the only real problem I have with your argument: you
persistently
> > overstate your case.
>
> Really? -->

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

Great!

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

Great. If it's a true continuation model, and if you don't want to
continue, you install a dumpcore() handler and you're done. EH can't
interfere. That's a much better solution than slicing off part of the
language to keep it from causing trouble.

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

Sorry, I mean that the mixing of hardware and C++ exceptions is a
platform-specific hack. Your technique is a workaround for a design bug.
It's a fine workaround, but it's not the ideal for C++ as a whole.

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

Yeah, it's a good one.

> 2) Avoid catch(...)

I have a serious problem with this one. catch(...) was a well-designed part
of the language and works perfectly well on lots of platforms. I don't like
guidelines which tell us to avoid things in C++ that are perfectly good in
design just because some implementations have screwed them up. We don't
tell people to avoid using partial specialization just because some
compilers fail to support it. We don't tell people to avoid exceptions just
because lots of older implementations (many still in use) have EH bugs. We
don't tell people to avoid optimization just because lots of compilers have
optimizer bugs.

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

No, not "on Windows", but on Microsoft, Intel, and Borland C++ targeting
32-bit Windows. If you use GCC or Metrowerks (in its "zero overhead" EH
mode) you don't have that problem. If you use Microsoft to target 64-bit
Windows you (reportedly) don't have that problem.

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

Good for you! BTW, how does catch(...) lead to silent data corruption? I
can see how it might cover a bug, but the corruption originated
elsewhere... this seems like another example of overstating your case.

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

#1 is a reasonably good guideline, but I'm still reluctant to accept it as
an absolute rule in the way you keep suggesting.

-Dave