Re: [boost] Boost and exceptions

Subject: Re: [boost] Boost and exceptions
From: Fabio Fracassi (f.fracassi_at_[hidden])
Date: 2012-06-23 05:15:47

On 6/22/12 9:55 PM, Robert Ramey wrote:
> 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.
>

Ok, let me rephrase that, it solves the problem for any application 
which have it. Without harming others. More functionality is good! (and 
yes I know that more functionality has a cost)

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

Of course I can, and that's what I end up doing. Its just onerous, and 
because I know that there is an easier and cleaner way it feels like a
workaround hack.

As Roger Martin stated in another reply: "I use this heavily and it 
works great while simplifying  code considerably.  Got rid of bubbling 
errors and multiple ways to do exceptions/errors. When the unified boost 
exceptions  came into existence tried them and immediately found a 
difference in code style, code size, readability and code maintenance"

Boost Exception allows me to ignore the issue, I don't even have to know 
if a peace of code does threading and needs it, it will just work when I 
do. These kind of 'Abstraction Enablers' provide real progress for 
programming in general, much more than the concrete functionality value 
alone.

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

Thats what I gathered, and what I disagree with. IMVHO This stance you 
take does not scale.

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

That is how modular development works, you let go of some control in 
exchange for synergy effects and free added functionality.
Yes, it creates communication overhead but the win (for the users) is huge.

regards

Fabio