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