Distinguishing error types
You can distinguish errors by type, that is, by how they’re made.
Knowing the error types helps you understand where to look in an application
for poten-tial problems. Exceptions work like many other things in life. For
example, you know that electronic devices don’t work without power. So, when
you try to turn your television on and it doesn’t do anything, you might look
to ensure that the power cord is firmly seated in the socket.
Understanding the error types helps you locate errors faster,
earlier, and more consistently, resulting in fewer misdiagnoses. The best
developers know that fixing errors while an application is in development is
always easier than fixing it when the application is in production because
users are inherently impa-tient and want errors fixed immediately and
correctly. In addition, fixing an error earlier in the development cycle is
always easier than fixing it when the application nears completion because less
code exists to review.
The trick is to know where to look. With this in mind, Python (and
most other programming languages) breaks errors into the following types:
- Syntactical
- Semantic
- Logical
The following sections examine each of these error types in more
detail. I’ve arranged the sections in order of difficulty, starting with the
easiest to find. A syntactical error is generally the easiest; a logical error
is generally the hardest.
Syntactical
Whenever you make a typo of some sort, you create a syntactical
error. Some Python syntactical errors are quite easy to find because the
application simply doesn’t run. The interpreter may even point out the error
for you by highlighting the errant code and displaying an error message.
However, some syntactical errors are quite hard to find. Python is case
sensitive, so you may use the wrong case for a variable in one place and find
that the variable isn’t quite working as you thought it would. Finding the one
place where you used the wrong capitalization can be quite challenging.
Most syntactical errors occur at compile time and the interpreter
points them out for you. Fixing the error is made easy because the interpreter
generally tells you what to fix, and with considerable accuracy. Even when the
interpreter doesn’t find the problem, syntactical errors prevent the
application from running correctly, so any errors the interpreter doesn’t find
show up during the testing phase. Few syntactical errors should make it into
production as long as you perform adequate application testing.
Semantic
When you create a loop that executes one too many times, you don’t
generally receive any sort of error information from the application. The
application will happily run because it thinks that it’s doing everything
correctly, but that one additional loop can cause all sorts of data errors.
When you create an error of this sort in your code, it’s called a semantic
error.
Semantic errors occur because the meaning behind a series of steps
used to perform a task is wrong — the result is incorrect even though the code
apparently runs precisely as it should. Semantic errors are tough to find, and
you sometimes need some sort of debugger to find them
Logical
Some developers don’t create a division between semantic and
logical errors, but they are different. A semantic error occurs when the code
is essentially correct but the implementation is wrong (such as having a loop
execute once too often). Logical errors occur when the developer’s thinking is
faulty. In many cases, this sort of error happens when the developer uses a
relational or logical operator incorrectly. However, logical errors can happen
in all sorts of other ways, too. For example, a developer might think that data
is always stored on the local hard drive, which means that the application may
behave in an unusual manner when it attempts to load data from a network drive
instead.
Logical errors are quite hard to fix because the problem isn’t
with the actual code, yet the code itself is incorrectly defined. The thought
process that went into creating the code is faulty; therefore, the developer
who created the error is less likely to find it. Smart developers use a second
pair of eyes to help spot logical errors. Having a formal application
specification also helps because the logic behind the tasks the application
performs is usually given a formal review.
Catching Exceptions
Generally speaking, a user should never see an exception dialog
box. Your application should always catch the exception and handle it before
the user sees it. Of course, the real world is different — users do see
unexpected exceptions from time to time. However, catching every potential
exception is still the goal when developing an application. The following
sections describe how to catch exceptions and handle them.
Understanding the built-in exceptions
Python comes with a host of built-in exceptions — far more than
you might think possible. You can see a list of these exceptions. The
documentation breaks the exception list down into categories. Here is a brief
overview of the Python exception categories that you work with regularly:
Base classes: The base
classes provide the essential building blocks (such as the Exception exception)
for other exceptions. However, you might actually see some of these
exceptions, such as the ArithmeticError exception, when working with an
application.
Concrete exceptions:
Applications can experience hard errors — errors that are hard to overcome
because there really isn’t a good way to handle them or they signal an event
that the application must handle. For example, when a system runs out of
memory, Python generates a MemoryError exception. Recovering from this error is
hard because it isn’t always possible to release memory from other uses. When
the user presses an interrupt key (such as Ctrl+C or Delete), Python gener
ates a KeyboardInterrupt exception. The application must handle this exception
before proceeding with any other tasks.
OS exceptions: The
operating system can generate errors that Python then passes them along to your
application. For exam ple, if your application tries to open a file that
doesn’t exist, the operating system generates a FileNotFoundError exception.
Warnings: Python tries to
warn you about unexpected events or actions that could result in errors later.
For example, if you try to inappropriately use a resource, such as an icon,
Python generates a
ResourceWarning exception. It’s important to remember that this
particular category is a warning and not an actual error: Ignoring it can cause
you woe later, but you can ignore it.
0 comments:
Post a Comment