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

From: Hillel Y. Sims (hsims_at_[hidden])
Date: 2002-08-14 09:05:40

"David Abrahams" <dave_at_[hidden]> wrote in message
news:0cc001c24340$6ee207b0$6501a8c0_at_boostconsulting.com...
> From: "Hillel Y. Sims" <hsims_at_[hidden]>
> > "David Abrahams" <dave_at_[hidden]> wrote in message
> > > 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?
>

Hmm. Interesting. (Why does std::exception provide a virtual dtor if it's
not really necessary?)

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

Thanks.

>
> > Maybe it's 99.44% "good enough" for most Windows software, and the
> > remaining 0.66% will be fixed "someday",

99.44 + 0.66 == 100??? *sigh* Good thing they keep me away from the
math-oriented apps...

>
> BTW, how does catch(...) lead to silent data corruption? I
> can see how it might cover a bug, but the corruption originated
> elsewhere...

Yup, but then the catch(...) can either mask it (in dtor-based {} swallow
situations) or run normal (non-hardware-exception-based) cleanup handling,
making a bad situation worse.

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

How about something along the lines of "Inherit user-defined exception
objects from std::exception unless you have a really good reason to do
otherwise"?

hys

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