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