Re: [boost] Boost and exceptions

Subject: Re: [boost] Boost and exceptions
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2012-06-23 00:37:47

I took some time to dig up and read some earlier threads on this. Major
deja vu here, yo.

On Wed, Jun 20, 2012 at 2:55 PM, Robert Ramey <ramey_at_[hidden]> wrote:

> Jeffrey Lee Hellrung, Jr. wrote:
>
[...]

> > For some
> >> unfathonable reason, the change in boost::throw_exception was
> >> allowed to stand.  So these libraries including serialization,
> >> boost.filesystem, and some
> >> others had to creat their own macros to implement the behavior of the
> >> original boost::throw_exception.
> >
>
> > Was actual code broken due to the change,
>
> Well it was noticed because it created problems.
>

> > and, if so, do you remember any examples?
>
> of course not. I suppose you could troll the list if you were
> really interested.
>

I was and I did.

I've found 2 threads which seem to refer to problems observed in
Boost.Serialization due to the Boost.Exception update of
boost::throw_exception.

One thread [1] (dated from May 2008) mentions the error of using
throw_exception to throw non-class types and class types which do not
inherit from std::exception; that specific requirement was not explicitly
documented prior to the Exception update of throw_exception and only
implicitly documented based on the code and the signature of the
user-defined hook. It seems like this root cause of the original problem
was identified fairly quickly. A fix to Serialization was or would have
been fairly trivial, but I guess introduced or would have introduced a
minor backward-compatibility issue...?

A second thread [2] (dated August 2008) started by Robert mentions "issues
with the serialization library" which prompted him to "investigate
boost/throw_exception.hpp", but...I couldn't find any reference to said
issues :(

> Or were those libraries authors who reimplemented the
> > original functionality simply concerned with the overhead introduced
> > by boost::throw_exception?
>
> Here's the real situation.  One invests a HUGE amount of effort
> that it takes to get a libary over the various boost hurdles.  I don't
> think
> very many people have any idea what it takes to get something
> like file_system, serialization, or others into boost.  After this
> huge initial effort you've got to spend some time cleaning up some
> detail and handling user complaints, upgrading documentation etc.
> (don't even mention the time it takes to deal with boost tools).
> So now you can sort of relax as things settle down, you've responded
> to all the questions by upgrading your documentation, etc. etc.
> Of course by the time this happens, you're way behind on your
> "real" work and trying to catch up with that.
>

Understood!

Then you get a problem. OK well you made the library, you better
> fix it.  After a fair amount of sleuthing, you track it down to a
> gratuitous
> change to some other library whose behavior has changed without
> you noticing.

I presume "some other library" == boost::throw_exception? AFACT, any
behavioral changes to throw_exception were *intended* to be fully backward
compatible. So I would think that any *breaking* changes as you describe
should (or should have been) filed as a bug against boost::throw_exception.

 This is incredibly disheartening. You've invested huge
> amount of effort to get something of this scale "over the hump" and
> now you've been undermined by someone who really isn't being
> considerate and/or doesn't know the implications of what he's doing.
>

Sorry, this sounds is starting to sound like an unfair personal attack
against the individual (Emil) who happened to spearhead the changes to
boost::throw_exception. AFAICT, some of the proposed changes to
boost::throw_exception did not originate with Emil, and ultimately there
was enough consensus from the community to move forward with these proposed
changes (whether this was right or wrong is another issue).

And, if accepted, this would mean a whole new level of effort you have
> to engage in - just to keep things from breaking.
>
> Originally you dealt with this by building a moat around your app/library
> and you only depend on other aps/libraries which you can really trust
> to not let you down.  So you do the only thing you really can do.  You
> tweak you app so it doesn't depend on the offending component any
> more.

Although I understand your motivations, I still find it a little ironic
that in your endeavor to rid yourself of boost::throw_exception you
introduced a breaking change to Boost.Serialization [3].

In any case, this isn't the only thing you can do. One could work with
community to iron out any issues with your use of boost::throw_exception.

 You have to do this be it just takes too much time to really
> investigate the implications of introducing a dependency on a new
> library just to relplace a simple macro.  So now your off the hook
> and you can move on with your life - but boost itself is worse off
> because of it since now the code base is more confusing and
> includes replicated functionality which it didn't have before.
>

Yes, I agree, it is worse off.

[...snip back-stabbing...]

And it's even bigger than this.  Have you noticed that in many shops
> the ONLY external library they permit is boost?  Have you noticed
> that the first place people look for C++ code is boost - even though
> there are at least 100's (maybe 1000's) of C++ code modules
> available at the touch of a buttone.  It's two things
>
> a) The review process - which catches most of the situations like this.
> b) Requirement for a test suite and regular execution thereof.
>
> these two things diminish problems like the example here. To me
> this situation is break down in the revew process - which thankfully
> is rare.  If situations like this were to occur on a regular basis
> boost wouldn't be nearly as successful as it has been.
>

AFAIK, many Boost-wide decisions are made via consensus among the Boost
community. This appears to me to be such a decision.

> I hope it  should be obvious that I don't see posts like:
> "you're wrong - it doesn't take that long to compile (anymore)" or
> "it doesn't have this problem (anymore)" are not really relevant to
> my concerns. They just miss the real point.
>

I don't think they do miss the real point. Backward compatible changes
should be allowed to be introduced into any Boost component, but this
obviously carries a risk that what an author *thinks* is backward
compatible actually breaks something; that's a bug in said component. If
the bug is addressed, everyone's happy, right?

Even if you don't agree, your side of the story would still be more
convincing if you could be more concrete about the actual problems
introduced by the Boost.Exception update of boost::throw_exception.

[...]

> FWIW, I think boost.exception would have had much better reception from
> other authors if the author had
>
> a)  implemented as I proposed.
> b) let it "rippen" over a couple of releases.
> c) made a pitch/case to other library authors about what the benefits would
> be if his library were included instead of the traditional way of doing
> things
> d) explained how users would appreciate the "upgrade".
> e) explained how there wouldn't be any downsides.
> f) explained how the library author wouldn't really have to do anything but
> a couple of simple edits.
> g) and accepted the fact that it would take time for people to migrate.
> h) and accepted the fact that in spite of his best efforts, he might not be
> able to convince everyone.
>
> I know it seems like it's a lot easier to just ram it down everyone's
> throat
> while they're
> attention is focused elsewhere.  And it likely is - in the short run.  But
> hopefully this thread might
> convince the next person considers this strategy that it's not really the
> shortcut it would seem to be.
>

Well I'm not sure duplicating existing functionality is any good either,
especially if it requires double the work from Boost users. At the point at
which you uncovered the issues with boost::throw_exception as they related
to Boost.Serialization, you had already "lost the boost::throw_exception
battle" (based only on my reading of the list archives; perhaps you have a
different recollection of events). As such, I think everyone would have
been better served in the long run by working with Emil and others in
addressing any regressions caused by the boost::throw_exception changes
rather than forking your own Boost.Serialization-local throw_exception,
doubling code and documentation effort, and forcing Boost users to define
and keep track two user-specified functions upon disabling of exceptions.

- Jeff

[1] http://lists.boost.org/Archives/boost/2008/05/136919.php
[2] http://lists.boost.org/Archives/boost/2008/08/141187.php
[3] http://lists.boost.org/Archives/boost/2008/09/142162.php