Re: [boost] Boost and exceptions

Subject: Re: [boost] Boost and exceptions
From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2012-06-20 18:06:10

On 20/06/2012 23:55, Robert Ramey wrote:

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

A certain level of quality of expected, but calling it huge is an 
overstatement. A lot of large software development companies have much 
stricter requirements and expectations for software quality before they 
ship it.

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

Maintenance is part of software development. Software is never finished 
and always requires more work. Software that has ceased to be maintained 
may as well be thrown away.

There will *always* be problems as new architectures, new compilers, new 
version of dependencies get introduced. No software is bug free.

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

This is why we have tests. When doing development on anything, with 
possibly several other things using it or depending on it, it is 
expected that doing changes might break things.

Doing regular tests on a full matrix of compilers and configurations can 
be used to clearly identify when a problem was introduced, what it is 
and in what situations and configurations it causes problems.

Of course, this needs a good testing mechanism in place to clearly 
identify which commit is responsible for a test breaking.
Boost has something a bit like this, but my guess is that you don't 
really make use of it in your developments. Efforts are being made by 
Dave and others to move to better tools (in this case buildbot) to make 
the whole of Boost more productive.

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

You normally only need to take such actions for the stable version of 
your library, not for the development branch.

It has been suggested that each library should have its own stable branch.

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

Most software development involves working with other people. It can 
indeed be annoying when someone breaks your stuff by making a change 
elsewhere in the code. It happens every day in the projects I work on. 
It's part of the job.

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

I've personally found that Boost.Exception has quite a few problems, yet 
it has some useful functionality that sometimes I need.

Don't use it when you don't need it, use it when you do. But as far as 
throw_exception is concerned, it's pretty much as if it weren't there.

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

BOOST_NO_EXCEPTIONS is defined if it is detected that the compiler has 
disabled exceptions.

Users may also manually define BOOST_NO_EXCEPTIONS to disable exceptions 
regardless of what is detected (useful for compilers which lack a 
mechanism to disable exceptions explicitly or where it cannot be detected).