93 lines
5.9 KiB
HTML
93 lines
5.9 KiB
HTML
|
<!DOCTYPE HTML PUBLIC "-//W3O//DTD W3 HTML 2.0//EN">
|
||
|
|
<!Converted with LaTeX2HTML 0.6.5 (Tue Nov 15 1994) by Nikos Drakos (nikos@cbl.leeds.ac.uk), CBLU, University of Leeds >
|
||
|
|
<HEAD>
|
||
|
|
<TITLE>29.1. Introduction</TITLE>
|
||
|
|
</HEAD>
|
||
|
|
<BODY>
|
||
|
|
<meta name="description" value=" Introduction">
|
||
|
|
<meta name="keywords" value="clm">
|
||
|
|
<meta name="resource-type" value="document">
|
||
|
|
<meta name="distribution" value="global">
|
||
|
|
<P>
|
||
|
|
<b>Common Lisp the Language, 2nd Edition</b>
|
||
|
|
<BR> <HR><A NAME=tex2html5593 HREF="node314.html"><IMG ALIGN=BOTTOM ALT="next" SRC="icons/next_motif.gif"></A> <A NAME=tex2html5591 HREF="node312.html"><IMG ALIGN=BOTTOM ALT="up" SRC="icons/up_motif.gif"></A> <A NAME=tex2html5585 HREF="node312.html"><IMG ALIGN=BOTTOM ALT="previous" SRC="icons/previous_motif.gif"></A> <A NAME=tex2html5595 HREF="node1.html"><IMG ALIGN=BOTTOM ALT="contents" SRC="icons/contents_motif.gif"></A> <A NAME=tex2html5596 HREF="index.html"><IMG ALIGN=BOTTOM ALT="index" SRC="icons/index_motif.gif"></A> <BR>
|
||
|
|
<B> Next:</B> <A NAME=tex2html5594 HREF="node314.html"> Changes in Terminology</A>
|
||
|
|
<B>Up:</B> <A NAME=tex2html5592 HREF="node312.html"> Conditions</A>
|
||
|
|
<B> Previous:</B> <A NAME=tex2html5586 HREF="node312.html"> Conditions</A>
|
||
|
|
<HR> <P>
|
||
|
|
<H1><A NAME=SECTION003310000000000000000>29.1. Introduction</A></H1>
|
||
|
|
<P>
|
||
|
|
<img align=bottom alt="change_begin" src="gif/change_begin.gif"><br>
|
||
|
|
Often we find it useful to describe a function in terms of its behavior in
|
||
|
|
``normal situations.'' For example, we may say informally that the function
|
||
|
|
<tt>+</tt> returns the sum of its arguments or that the function
|
||
|
|
<tt>read-char</tt> returns the next available character on a given input
|
||
|
|
stream.
|
||
|
|
<P>
|
||
|
|
Sometimes, however, an ``exceptional situation'' will arise that does not fit
|
||
|
|
neatly into such descriptions. For example, <tt>+</tt> might receive an argument
|
||
|
|
that is not a number, or <tt>read-char</tt> might receive as a single argument
|
||
|
|
a stream that has no more available characters. This distinction between normal
|
||
|
|
and exceptional situations is in some sense arbitrary but is often very
|
||
|
|
useful in practice.
|
||
|
|
<P>
|
||
|
|
For example, suppose a function <tt>f</tt> were defined to allow only
|
||
|
|
integer arguments but also guaranteed to
|
||
|
|
detect and signal an error for non-integer arguments.
|
||
|
|
Such a description is in fact internally inconsistent (that is,
|
||
|
|
paradoxical) because the function's behavior is well-defined for non-integers.
|
||
|
|
Yet we would not want this annoying paradox to force description of <tt>f</tt>
|
||
|
|
as a function that accepts any kind of argument (just in case <tt>f</tt>
|
||
|
|
is being called only as a quick way to signal an error, for example).
|
||
|
|
Using the normal/exceptional distinction, we can say clearly that <tt>f</tt> accepts integers
|
||
|
|
in the normal situation and signals an error in exceptional situations.
|
||
|
|
Moreover, we can say that when we refer to the definition of a
|
||
|
|
function informally, it is acceptable to speak only of its normal behavior.
|
||
|
|
For example, we can speak informally about <tt>f</tt> as a function that accepts only
|
||
|
|
integers without feeling that we are committing some awful fraud.
|
||
|
|
<P>
|
||
|
|
Not all exceptional situations are errors. For example, a program that is
|
||
|
|
directing the typing of a long line of text may come to an end-of-line.
|
||
|
|
It is possible that no real harm will result from failing to signal end-of-line
|
||
|
|
to its caller because the operating system will simply force a carriage
|
||
|
|
return on the output device, which will continue typing on the next line. However, it
|
||
|
|
may still be interesting to establish a protocol whereby the printing program can
|
||
|
|
inform its caller of end-of-line exceptions. The caller could
|
||
|
|
then opt to deal with these situations in interesting ways at certain times.
|
||
|
|
For example, a caller might choose to terminate printing, obtaining an end-of-line
|
||
|
|
truncation. The important thing, however, is that the failure of the
|
||
|
|
caller to provide advice about the situation need not prevent
|
||
|
|
the printer program from operating correctly.
|
||
|
|
<P>
|
||
|
|
Mechanisms for dealing with exceptional situations vary widely. When an
|
||
|
|
exceptional situation is encountered, a program may attempt to handle
|
||
|
|
it by returning a distinguished value, returning an additional value,
|
||
|
|
setting a variable, calling a function, performing a special transfer of
|
||
|
|
control, or stopping the program altogether and entering the debugger.
|
||
|
|
<P>
|
||
|
|
For the most part, the facilities described in this chapter do not introduce
|
||
|
|
any fundamentally new way of dealing with exceptional situations. Rather, they
|
||
|
|
encapsulate and formalize useful patterns of data and control flow that have
|
||
|
|
been seen to be useful in dealing with exceptional situations.
|
||
|
|
<P>
|
||
|
|
A proper conceptual approach to errors should perhaps begin from first
|
||
|
|
principles, with a discussion of <i>conditions</i> in general, and eventually work
|
||
|
|
up to the concept of an <i>error</i> as just one of the many kinds of
|
||
|
|
conditions. However, given the primitive state of error-handling
|
||
|
|
technology, a proper buildup may be as inappropriate as requiring that a
|
||
|
|
beggar learn to cook a gourmet meal before being allowed to eat. Thus,
|
||
|
|
we deal first with the essentials-error handling-and then
|
||
|
|
go back later to fill in the missing details.
|
||
|
|
<br><img align=bottom alt="change_end" src="gif/change_end.gif">
|
||
|
|
<P>
|
||
|
|
<BR> <HR><A NAME=tex2html5593 HREF="node314.html"><IMG ALIGN=BOTTOM ALT="next" SRC="icons/next_motif.gif"></A> <A NAME=tex2html5591 HREF="node312.html"><IMG ALIGN=BOTTOM ALT="up" SRC="icons/up_motif.gif"></A> <A NAME=tex2html5585 HREF="node312.html"><IMG ALIGN=BOTTOM ALT="previous" SRC="icons/previous_motif.gif"></A> <A NAME=tex2html5595 HREF="node1.html"><IMG ALIGN=BOTTOM ALT="contents" SRC="icons/contents_motif.gif"></A> <A NAME=tex2html5596 HREF="index.html"><IMG ALIGN=BOTTOM ALT="index" SRC="icons/index_motif.gif"></A> <BR>
|
||
|
|
<B> Next:</B> <A NAME=tex2html5594 HREF="node314.html"> Changes in Terminology</A>
|
||
|
|
<B>Up:</B> <A NAME=tex2html5592 HREF="node312.html"> Conditions</A>
|
||
|
|
<B> Previous:</B> <A NAME=tex2html5586 HREF="node312.html"> Conditions</A>
|
||
|
|
<HR> <P>
|
||
|
|
<HR>
|
||
|
|
<P><ADDRESS>
|
||
|
|
AI.Repository@cs.cmu.edu
|
||
|
|
</ADDRESS>
|
||
|
|
</BODY>
|