David Abrahams
Rationales, for what? Cleaner than what?
this is more or less my interpretation of chapter 14 of Stroustrup's book 'The C++ programming language'.
That fact doesn't seem to answer either question.
Maybe I may quote mr Stroustrup in his book: "The exception handling mechanism provides an alternative to the traditional techniques when they are insufficient, inelegant and error prone. It provides a way of explicitly separating error handling code from 'ordinary' code, thus making the program more readable and more emenable to tools" (etc.) I ran across a nice mail thread which a lots of pro's and cons about this matter: http://www.dbforums.com/archive/index.php/t-689599.html
... It's almost impossible to write reasonable programs when you have to "consider that one of the xxx objects can 'become' corrupt."
http://groups.google.com/group/comp.lang.c++.moderated/msg/659b9db50f587dab
... I don't know why anyone would do that. Which employee has 'become' corrupt here, and how does the above code supposedly help? It seems to just eat exceptions and mask errors, nothing more.
In a way it is. One can think of let the progam just continue its work, but a repair action must be scheduled the next time. This can be defensive or make things worse depending on the problem context.
IME defensive measures almost always make things worse. As noted in the thread I reference above, nobody has really developed a discipline that tells us what things to defend against, when to stop checking, and what we can reliably do when a problem is found. The result tends to be programs full of "corruption checks" and bogus "recovery code" that never gets tested or executed, making the program much harder to debug and maintain. In my experience, that approach vastly increases the likelihood of bugs.
I have quite the opposite opinion: I work on a new version of a large application and the old team had a very strict exception policy which gave the application instability and crashes. Because of this experience we built a much more forgiveness (without sacrifycing data integrity) in the application, which makes it more robust. This does of course not mean that every pointer is checked, but an example can be that subsystems must check their arguments before continuing their work. Incorrect arguments will not be signaled by exceptions. wkr, me I should one day give my real name..