on Mon Mar 05 2007, gast128
David Abrahams
writes: Hello David,
Another item is that I think that one of the rationales is that it is cleaner to write code like:
void Foo() { try { //write logic } catch () { //write exception case(s) } }
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.
... 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. -- Dave Abrahams Boost Consulting www.boost-consulting.com