Most application code of any complexity has errors in it. When
your application suddenly freezes for no apparent reason, that’s an error.
Seeing one of those obscure message dialog boxes is another kind of error.
However, errors can happen and does not provide you with any sort of
notification.
An application might perform the wrong calculation a series of
numbers you provide, resulting in incorrect output that you will never know
about unless someone tells you that something is wrong or you check for the problem
yourself. You may see errors at some occasions and not on others. For example,
an error can occur only when the weather is bad or the network is overloaded.
In short, errors occur in any sorts of situations and for any sorts of reasons.
This post shall tell you about all sorts of errors and what to do when your
application encounters them.
It shouldn’t surprise you that errors occur — applications are
written by humans, and humans make mistakes. Most developers call application
errors exceptions, meaning that they’re the exception to the rule. Because
exceptions do occur in applications, you need to find them and do something
about them whenever possible. The act of finding and processing an exception is
called error handling or exception handling. In order to properly process
errors, you need to know about error sources and why the error has occurred in
the first place. When you find the error, you must process it by catching the
exception. Catching an exception means examining it and doing something about
it. So, another part of this post is about discovering how to perform exception
handling in your own application.
Sometimes your code detects an error in the application. When this
happens, you need to raise or throw an exception. You see both terms used for
the same thing, which simply means that your code encountered an error it
couldn’t handle, so it passed the error information onto another piece of code
to handle (interpret, process, and, with luck, fix the exception). In some
cases, you use custom error message objects to pass on the information. It’s
important to know when to handle exceptions locally, when to send them to the
code that called your code, and when to create special exceptions so that every
part of the application knows how to handle the exception.
There are also times when you must ensure that your application
handles an exception gracefully, even if that means shutting the application
down. Fortunately, Python provides the finally clause, which always executes,
even when an exception occurs. You can place code to close files or perform
other essential tasks in the code block associated with this clause. Even
though you won’t perform this task all the time.
Developers often get frustrated with programming languages and computers
because they seemingly go out of their way to cause communication
problems.Neither Python nor the computer will “know what you mean” when you
type instructions as code. Both follow whatever instructions you provide to the
letter and literally as you provide them. You may not have meant to tell Python
to delete a data file unless some absurd condition occurred. However, if you
don’t make the conditions clear, Python will delete the file whether the
condition exists or not. When an error of this sort happens, people commonly
say that the application has a bug in it. Bugs are simply coding errors that
you can remove using a debugger. (A debugger is a special kind of tool that
lets you stop or pause application execution, examine the content of variables,
and generally dissect the application to see what makes it tick.)
Errors occur in many cases when the developer makes assumptions
that simply aren’t true. Of course, this includes assumptions about the
application user, who probably doesn’t care about the extreme level of care you
took when developing your application. The user will enter wrong data. Again,
Python won’t know or care that the data is wrong and will process it even when
your intent was to disallow the bad input. Python doesn’t understand the
concepts of right or data; it simply processes incoming data according to any
rules you set, which means that you must set rules to protect users from
themselves.
When a network error occurs or the user does something unexpected,
Python doesn’t create a solution to fix the problem on its own. It only
processes code. If you don’t provide code to handle the error, the application
is likely to fail and crash ungracefully — possibly taking all of the user’s
data with it.
Some developers out there think they can create bulletproof code,
despite the absurdity of thinking that such code is even possible. Smart
developers assume that some number of bugs will get through the code-screening
process, that nature and users will continue to perform unexpected actions, and
that even the smartest developer can’t anticipate every possible error
condition. Always assume that your application is subjected to errors that will
cause exceptions; that way, you’ll have the mindset required to actually make
your application more reliable.
Considering the Sources of Errors
You might be able to divine the potential sources of error in your
applica-tion by reading tea leaves, but that’s hardly an efficient way to do
things. Errors actually fall into well-defined categories that help you predict
(to some degree) when and where they’ll occur. By thinking about these
categories as you work through your application, you’re far more likely to
discover poten-tial errors sources before they occur and cause potential
damage. The two principle categories are
Errors that occur at a specific
time
Errors that are of a
specific type
The following sections discuss these two categories in greater
detail. The overall concept is that you need to think about error
classifications in order to start finding and fixing potential errors in your
application before they become a problem.
Classifying when errors occur
Errors occur at specific times. The two major time frames are
- Compile
time
- Run time
No matter when an error occurs, it causes your application to
misbehave. The following sections describe each time frame.
Compile time
A compile time error occurs when you ask Python to run the
application. Before Python can run the application, it must interpret the code
and put it into a form that the computer can understand. A computer relies on
machine code that is specific to that processor and architecture. If the
instructions you write are malformed or lack needed information, Python can’t
perform the required conversion. It presents an error that you must fix before
the application can run.
Fortunately, compile-time errors are the easiest to spot and fix.
Because the application won’t run with a compile-time error in place, user
never sees this error category. You fix this sort of error as you write your
code.
The appearance of a compile-time error should tell you that other
typos or omissions could exist in the code. It always pays to check the
surrounding code to ensure that no other potential problems exist that might
not show up as part of the compile cycle.
Runtime
A runtime error occurs after Python compiles the code you write
and the com-puter begins to execute it. Runtime errors come in several
different types, and some are harder to find than others. You know you have a
runtime error when the application suddenly stops running and displays an
exception dialog box or when the user complains about erroneous output (or at
least instability).
Not all runtime errors produce an exception. Some runtime errors
cause instabil-ity (the application freezes), errant output, or data damage.
Runtime errors can affect other applications or create unforeseen damage to the
platform on which the application is running. In short, runtime errors can
cause you quite a bit of grief, depending on precisely the kind of error you’re
dealing with at the time.
Many runtime errors are caused by errant code. For example, you
can mis-spell the name of a variable, preventing Python from placing
information in the correct variable during execution. Leaving out an optional
but necessary argument when calling a method can also cause problems. These are
exam-ples of errors of commission, which are specific errors associated with
your code. In general, you can find these kinds of errors using a debugger or
by simply reading your code line by line to check for errors.
Runtime errors can also be caused by external sources not
associated with your code. For example, the user can input incorrect
information that the application isn’t expecting, causing an exception. A network
error can make a required resource inaccessible. Sometimes even the computer
hardware has a glitch that causes a nonrepeatable application error. These are
all examples of errors of omission, from which the application might recover if
your appli-cation has error-trapping code in place. It’s important that you
consider both kinds of runtime errors — errors of commission and omission —
when build-ing your application.
0 comments:
Post a Comment