Re: [boost] Boost and exceptions

Subject: Re: [boost] Boost and exceptions
From: Robert Ramey (ramey_at_[hidden])
Date: 2012-06-20 17:55:00

Jeffrey Lee Hellrung, Jr. wrote:

> Longer build time, dependence on a new library, new
>> requirement that the library be only used with rtti turned on.
>
>
> At this point, based on Emil's and John's responses, it seems these
> first 2 issues aren't really problems in practice, while the 3rd
> issue is simply
> not the case.

It may or may not be the case now. This isn't really relevant to my 
complaint
as you'll see below

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

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

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

And it's even worse -  Basically it's like an army where everyone wears
the same uniform.  Now someone with the same uniform as you stabs
you in the back, and now you can't trust anyone anymore. So
all the assumptions that you used to be able to make - (e.g.
I'm not going to be surprised by something out of left field)
aren't true any more.  So it slows everyone down in the future.

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.

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.

Honestly, I have no opinion at all on the merits of boost exception.
Even more honest, I haven't even looked at the documentation or
code.  This is not about boost exception - its about how a developer
can be expected to cope if this practice is permited to continue.

> Okay, fair enough; this is an understandable but more philosophical
> point concerning development practices.

right. For me it is the main point.

> At this point, though,
> boost::throw_exception has had these semantics since...well whenever
> Boost.Exception was released, which appears to be 1.36 based on my
> changing the version number in the URL of the documentation of
> boost::throw_exception :/ And it seems like changing it *back* to the
> pre-1.36 functionality would break more code than the change
> introduced in
> 1.36.

lol I didn't follow that. It doesn't matter though as we've already excluded
it from our libraries and are unlikely to go back and revisit it as we've
got other fish to fry.

>> (For the record, I've glanced at the blurbs on BOOST_NO_EXCEPTIONS
>>> within Boost.Config and Boost.Exception and it's difficult for me to
>>> parse what effect their differences have in practice, and it sounds
>>> like others have a good idea what the problem seems to be.)
>>
>> I hope I clarified this.
>>
>
> Clearly not entirely :)

lol - +1 I"m as confused as ever on the subject. From my standpoint,
I'm just that much more greatful that I severed the dependence on this 
library.

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.

Robert Ramey