According to MSDN Deep C++ by Robert Schmidt:
"At their core, program exceptions are conditions that arise
infrequently and unexpectedly, generally betray a program error, and
require a considered programmatic response. Failure to obey that
response often renders the affected program crippled or dead, sometimes
taking the entire system down with it. Unfortunately, crafting robust
code using traditional defensive techniques often trades one problem
(crashing exceptions) for another (more tangled design and code)."
"A software error occurs. This error may have originated as a
hardware-generated event (such as zero-divide) mapped into a software
error by a low-level driver or kernel."
"Next to outright ignoring an exception, probably the easiest response
is self-destruction. In some cases, that lazy response is actually the
correct response.
"Before you scoff, consider that some exceptions betray a condition so
severe that reasonable recovery is unlikely anyway. Perhaps the best
example is malloc of a small object returning NULL. If the free store
manager can't scrape together a few spare contiguous bytes, your
program's robustness is severely compromised, and the odds of elegant
recovery are slim."
On top of that, constructs such as COM Servers do not offer exception
handling and are dealt with via returns codes only.
I'm not suggesting exceptions have no place. Additionally, I've never
supported use of the 'goto'. I agree 100% exceptions are cleaner to
read and have the advantage of local/non-local handling. However,
exceptions do cost processing overhead and shouldn't be used for
"normal program control" (How to Program C++: 3rd Edition). If you can
handle an error locally, handle it. If not, consider if it is truly an
'error' or a 'state'.
