Re: We do not use C++ exceptions
On Feb 4, 2:35 pm, "Martin T." <0xCDCDC...@gmx.at> wrote:
*If* the code was able to detect some internal consistency problem,
then, by all means it *should* throw an exception. What else should it
do? Call abort(). exit(1)?? We had some libraries that did that. I tell
you, IMHO that's really a Bad Thing.
It is indeed a bad thing under some circumstances, which is why
exceptionism not only persists, but is winning.
It is a Bad thing when the library has so many bugs that it routinely
aborts, you have no access to its source or are not qualified enough
to fix it, and its developers are unwilling or unable to maintain it
properly.
Assertionism assumes a desire and ability to promptly fix the bugs
that are exposed by the asserts. The failure is made as visible as
possible in the hope that it will not be tolerated.
Exceptionism allows you to work around some of the failures without
modifying the library. You like the degree of control that you retain,
but the hidden cost is that the library is less likely to be fixed.
Yes, in theory, you could have the best of both worlds...
The application developer can still tell you you have a bug, because he
got a logic_error exception that either a) crashed his application
because it's not caught or b) he "logs" an unexpected error from the
library and can continue with other important stuff.
.... you could have a library that throws exceptions on unexpected
failures whose bugs are fixed at the same speed as they would be had
it asserted instead. But this doesn't happen in practice. The two
properties aren't orthogonal. Even when all of the information
required to identify and debug the failure is retained when the
exception is thrown, the library developer is still less likely to
receive a bug report for a failure that can be worked around, and
failures that have a workaround have lower priority in the issue
tracker.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]