| Thinking in C++ Vol 2 - Practical Programming |
|
Prev |
Home |
Next |
Exceptions aren t the answer to all problems; overuse can
cause trouble. The following sections point out situations where exceptions are
not warranted. The best advice for deciding when to use exceptions is to
throw exceptions only when a function fails to meet its specification.
Not for asynchronous events
The Standard C signal( ) system and any similar system handle asynchronous events: events that
happen outside the flow of a program, and thus events the program cannot
anticipate. You cannot use C++ exceptions to handle asynchronous events because
the exception and its handler are on the same call stack. That is, exceptions
rely on the dynamic chain of function calls on the program s runtime stack (they
have dynamic scope ), whereas asynchronous events must be handled by
completely separate code that is not part of the normal program flow
(typically, interrupt service routines or event loops). Don t throw exceptions
from interrupt handlers.
This is not to say that asynchronous events cannot be associated
with exceptions. But the interrupt handler should do its job as quickly as
possible and then return. The typical way to handle this situation is to set a
flag in the interrupt handler, and check it synchronously in the mainline code.
Not for benign error conditions
If you have enough information to handle an error, it s not
an exception. Take care of it in the current context rather than throwing an
exception to a larger context.
Also, C++ exceptions are not thrown for machine-level events
such as divide-by-zero. It s
assumed that some other mechanism, such as the operating system or hardware,
deals with these events. In this way, C++ exceptions can be reasonably
efficient, and their use is isolated to program-level exceptional conditions.
Not for flow of control
An exception looks somewhat like an alternate return
mechanism and somewhat like a switch statement, so you might be tempted
to use an exception instead of these ordinary language mechanisms. This is a
bad idea, partly because the exception-handling system is significantly less
efficient than normal program execution. Exceptions are a rare event, so the
normal program shouldn t pay for them. Also, exceptions from anything other
than error conditions are quite confusing to the user of your class or
function.
You re not forced to use exceptions
Some programs are quite simple (small utilities, for
example). You might only need to take input and perform some processing. In
these programs, you might attempt to allocate memory and fail, try to open a
file and fail, and so on. It is acceptable in these programs to display a
message and exit the program, allowing the system to clean up the mess, rather
than to work hard to catch all exceptions and recover all the resources
yourself. Basically, if you don t need exceptions, you re not forced to use
them.
New exceptions, old code
Another situation that arises is the modification of an
existing program that doesn t use exceptions. You might introduce a library
that does use exceptions and wonder if you need to modify all your code
throughout the program. Assuming you have an acceptable error-handling scheme
already in place, the most straightforward thing to do is surround the largest
block that uses the new library (this might be all the code in main( ))
with a try block, followed by a catch(...) and basic error
message). You can refine this to whatever degree necessary by adding more
specific handlers, but, in any case, the code you must add can be minimal. It s
even better to isolate your exception-generating code in a try block and
write handlers to convert the exceptions into your existing error-handling
scheme.
It s truly important to think about exceptions when you re
creating a library for someone else to use, especially if you can t know how
they need to respond to critical error conditions (recall the earlier
discussions on exception safety and why there are no exception specifications
in the Standard C++ Library).
| Thinking in C++ Vol 2 - Practical Programming |
|
Prev |
Home |
Next |
