Re: [boost] Boost and exceptions

Subject: Re: [boost] Boost and exceptions
From: Robert Ramey (ramey_at_[hidden])
Date: 2012-06-22 15:55:27

Fabio Fracassi wrote:
> On 6/22/12 8:58 AM, Robert Ramey wrote:
>
>> The problem was the gratuitious inclusion of a new
>> dependency.  The extent/nature of any problem it created or didn't
>> create is not relevant here.
>
> Yes it is, because in reality boost exception solves problems for the
> users of any library that uses it. When using boost exception I can
> safely let exceptions escape threads and have them rethrown in the
> starting thread, for instance.

well, not every application uses threads.  Really, I don't think anyone
can say "solves problems for ANY library which uses it." without
knowing what the application is.

>> Just the injection of a new body
>> of code which replaced two lines and added no functionality
>> used/needed by the serialization library makes the any library
>> which used boost::throw_exception "bigger" for no reason.
>
> It has a real and important reason, because it unifies boost exception
> handling, nearly for free. The few boost libraries which do not use
> it, serialization most notably, cause trouble because they need extra
> care to make exception handling well behaved.

Is there any reason you can't trap any exception from a library
and rethrow it using boost.exception in your own application?

>> It makes the library more "fragil".
>
> No, it gave your users more functionality in an area of which you were
> not even aware.

That's exactly what makes it more fragil.  From my standpoint, I'm on the
hook for any problem which occurs in the injected code.  Code actually
have no idea what it does.

>> It means I have I a new place
>> to look if something needs looking into. etc.etc.
>
> It is a shoulder (not quite a giants, but still) to stand on, which gives 
> you a higher reach!

Gives YOU a higher reach - at my expense.

I will say you've given a rousing endorsement of boost exception
and a good case for it's merits.

I'm not convinced that you've all the applications of boost libraries 
outside
your problem domain.  If someone wanted to take a serious look at the 
something
the serialization (or other library) and propose some enhance me - maybe via
a policy argument or whatever and create a TRAC item, that would be one
thng.  But for one person to inject code/depency  into a separate library 
because
he "knows better what users need" isn't a great idea (unless he wants to 
take
over maintainence of the library - which of course would be a whole 
different thing.

Robert Ramey

> regards
>
> Fabio