Readers with experience in other programming languages may equate
an exception with a kind of
changes the normal course of execution to a (possibly hard to find)
exception-handling suite. This is a correct description of the
construct, which leads to some difficult decision-making.
Some exception-causing conditions are actually predictable states
of the program. The notable exclusions are I/O Error, Memory Error and
OS Error. These three depend on resources outside the direct control of
the running program and Python interpreter. Exceptions like Zero
Division Error or Value Error can be checked with simple, clear
statements. Exceptions like Attribute Error or Not
Implemented Error should never occur in a program that is reasonably
well written and tested.
Relying on exceptions for garden-variety errors — those that are
easily spotted with careful design or testing — is often a sign of
shoddy programming. The usual story is that the programmer received the
exception during testing and simply added the exception processing
statement to work around the problem; the
programmer made no effort to determine the actual cause or remediation
for the exception.
In their defense, exceptions can simplify complex nested
statements. They can provide a clear
“escape” from complex logic when an exceptional condition
makes all of the complexity moot. Exceptions should be used sparingly,
and only when they clarify or simplify exposition of the algorithm. A
programmer should not expect the reader to search all over the program
source for the relevant exception-handling clause.
Future examples, which use I/O and OS calls, will benefit from
simple exception handling. However, exception laden programs are a
problem to interpret. Exception clauses are relatively expensive,
measured by the time spent to understand their intent.