77 lines
14 KiB
HTML
77 lines
14 KiB
HTML
<!-- Common Lisp HyperSpec (TM), version 7.0 generated by Kent M. Pitman on Mon, 11-Apr-2005 2:31am EDT -->
|
|
<HTML>
|
|
<HEAD>
|
|
<TITLE>CLHS: Section 1.4.2</TITLE>
|
|
<LINK HREF="../Data/clhs.css" REL="stylesheet" TYPE="text/css" />
|
|
<META HTTP-EQUIV="Author" CONTENT="Kent M. Pitman">
|
|
<META HTTP-EQUIV="Organization" CONTENT="LispWorks Ltd.">
|
|
<LINK REL=TOP HREF="../Front/index.htm">
|
|
<LINK REL=COPYRIGHT HREF="../Front/Help.htm#Legal">
|
|
<LINK REL=DISCLAIMER HREF="../Front/Help.htm#Disclaimer">
|
|
<LINK REL=PREV HREF="01_daf.htm">
|
|
<LINK REL=UP HREF="01_d.htm">
|
|
<LINK REL=NEXT HREF="01_dc.htm">
|
|
</HEAD>
|
|
<BODY>
|
|
<H1><A REV=MADE HREF="http://www.lispworks.com/"><IMG WIDTH=80 HEIGHT=65 ALT="[LISPWORKS]" SRC="../Graphics/LWSmall.gif" ALIGN=Bottom></A><A REL=TOP HREF="../Front/index.htm"><IMG WIDTH=237 HEIGHT=65 ALT="[Common Lisp HyperSpec (TM)]" SRC="../Graphics/CLHS_Sm.gif" ALIGN=Bottom></A> <A REL=PREV HREF="01_daf.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Previous]" SRC="../Graphics/Prev.gif" ALIGN=Bottom></A><A REL=UP HREF="01_d.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Up]" SRC="../Graphics/Up.gif" ALIGN=Bottom></A><A REL=NEXT HREF="01_dc.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Next]" SRC="../Graphics/Next.gif" ALIGN=Bottom></A></H1>
|
|
|
|
<HR>
|
|
|
|
<H2>
|
|
1.4.2 Error Terminology</H2> <P>
|
|
Situations in which errors might, should, or must be signaled are described in the standard. The wording used to describe such situations is intended to have precise meaning. The following list is a glossary of those meanings. <P>
|
|
<P><DL><DT><B>Safe code</B> <P><DD>
|
|
This is <A REL=DEFINITION HREF="26_glo_c.htm#code"><I>code</I></A> processed with the <A REL=DEFINITION HREF="d_optimi.htm#safety"><B>safety</B></A> optimization at its highest setting (<TT>3</TT>). <A REL=DEFINITION HREF="d_optimi.htm#safety"><B>safety</B></A> is a lexical property of code. The phrase ``the function <TT>F</TT> should signal an error'' means that if <TT>F</TT> is invoked from code processed with the highest <A REL=DEFINITION HREF="d_optimi.htm#safety"><B>safety</B></A> optimization, an error is signaled. It is <A REL=DEFINITION HREF="26_glo_i.htm#implementation-dependent"><I>implementation-dependent</I></A> whether <TT>F</TT> or the calling code signals the error. <P>
|
|
<DT><B>Unsafe code</B> <P><DD>
|
|
This is code processed with lower safety levels. <P>
|
|
Unsafe code might do error checking. Implementations are permitted to treat all code as safe code all the time. <P>
|
|
<DT><B>An error is signaled</B> <P><DD>
|
|
This means that an error is signaled in both safe and unsafe code. <A REL=DEFINITION HREF="26_glo_c.htm#conforming_code"><I>Conforming code</I></A> may rely on the fact that the error is signaled in both safe and unsafe code. Every implementation is required to detect the error in both safe and unsafe code. For example, ``an error is signaled if <A REL=DEFINITION HREF="f_unexpo.htm#unexport"><B>unexport</B></A> is given a <A REL=DEFINITION HREF="26_glo_s.htm#symbol"><I>symbol</I></A> not <A REL=DEFINITION HREF="26_glo_a.htm#accessible"><I>accessible</I></A> in the <A REL=DEFINITION HREF="26_glo_c.htm#current_package"><I>current package</I></A>.'' <P>
|
|
If an explicit error type is not specified, the default is <A REL=DEFINITION HREF="e_error.htm#error"><B>error</B></A>. <P>
|
|
<DT><B>An error should be signaled</B> <P><DD>
|
|
This means that an error is signaled in safe code, and an error might be signaled in unsafe code. <A REL=DEFINITION HREF="26_glo_c.htm#conforming_code"><I>Conforming code</I></A> may rely on the fact that the error is signaled in safe code. Every implementation is required to detect the error at least in safe code. When the error is not signaled, the ``consequences are undefined'' (see below). For example, ``<A REL=DEFINITION HREF="f_pl.htm#PL"><B>+</B></A> should signal an error of <A REL=DEFINITION HREF="26_glo_t.htm#type"><I>type</I></A> <A REL=DEFINITION HREF="e_tp_err.htm#type-error"><B>type-error</B></A> if any argument is not of <A REL=DEFINITION HREF="26_glo_t.htm#type"><I>type</I></A> <A REL=DEFINITION HREF="t_number.htm#number"><B>number</B></A>.'' <P>
|
|
<DT><B>Should be prepared to signal an error</B> <P><DD>
|
|
This is similar to ``should be signaled'' except that it does not imply that `extra effort' has to be taken on the part of an <A REL=DEFINITION HREF="26_glo_o.htm#operator"><I>operator</I></A> to discover an erroneous situation if the normal action of that <A REL=DEFINITION HREF="26_glo_o.htm#operator"><I>operator</I></A> can be performed successfully with only `lazy' checking. An <A REL=DEFINITION HREF="26_glo_i.htm#implementation"><I>implementation</I></A> is always permitted to signal an error, but even in <A REL=DEFINITION HREF="26_glo_s.htm#safe"><I>safe</I></A> <A REL=DEFINITION HREF="26_glo_c.htm#code"><I>code</I></A>, it is only required to signal the error when failing to signal it might lead to incorrect results. In <A REL=DEFINITION HREF="26_glo_u.htm#unsafe"><I>unsafe</I></A> <A REL=DEFINITION HREF="26_glo_c.htm#code"><I>code</I></A>, the consequences are undefined. <P>
|
|
For example, defining that ``<A REL=DEFINITION HREF="f_find_.htm#find"><B>find</B></A> should be prepared to signal an error of <A REL=DEFINITION HREF="26_glo_t.htm#type"><I>type</I></A> <A REL=DEFINITION HREF="e_tp_err.htm#type-error"><B>type-error</B></A> if its second <A REL=DEFINITION HREF="26_glo_a.htm#argument"><I>argument</I></A> is not a <A REL=DEFINITION HREF="26_glo_p.htm#proper_list"><I>proper list</I></A>'' does not imply that an error is always signaled. The <A REL=DEFINITION HREF="26_glo_f.htm#form"><I>form</I></A> <P>
|
|
<PRE>
|
|
(find 'a '(a b . c))
|
|
</PRE>
|
|
</TT> <P>
|
|
must either signal an error of <A REL=DEFINITION HREF="26_glo_t.htm#type"><I>type</I></A> <A REL=DEFINITION HREF="e_tp_err.htm#type-error"><B>type-error</B></A> in <A REL=DEFINITION HREF="26_glo_s.htm#safe"><I>safe</I></A> <A REL=DEFINITION HREF="26_glo_c.htm#code"><I>code</I></A>, else return <TT>A</TT>. In <A REL=DEFINITION HREF="26_glo_u.htm#unsafe"><I>unsafe</I></A> <A REL=DEFINITION HREF="26_glo_c.htm#code"><I>code</I></A>, the consequences are undefined. By contrast, <P>
|
|
<PRE>
|
|
(find 'd '(a b . c))
|
|
</PRE>
|
|
</TT> <P>
|
|
must signal an error of <A REL=DEFINITION HREF="26_glo_t.htm#type"><I>type</I></A> <A REL=DEFINITION HREF="e_tp_err.htm#type-error"><B>type-error</B></A> in <A REL=DEFINITION HREF="26_glo_s.htm#safe"><I>safe</I></A> <A REL=DEFINITION HREF="26_glo_c.htm#code"><I>code</I></A>. In <A REL=DEFINITION HREF="26_glo_u.htm#unsafe"><I>unsafe</I></A> <A REL=DEFINITION HREF="26_glo_c.htm#code"><I>code</I></A>, the consequences are undefined. Also, <P>
|
|
<PRE>
|
|
(find 'd '#1=(a b . #1#))
|
|
</PRE>
|
|
</TT> <P>
|
|
in <A REL=DEFINITION HREF="26_glo_s.htm#safe"><I>safe</I></A> <A REL=DEFINITION HREF="26_glo_c.htm#code"><I>code</I></A> might return <A REL=DEFINITION HREF="a_nil.htm#nil"><B>nil</B></A> (as an <A REL=DEFINITION HREF="26_glo_i.htm#implementation-defined"><I>implementation-defined</I></A> extension), might never return, or might signal an error of <A REL=DEFINITION HREF="26_glo_t.htm#type"><I>type</I></A> <A REL=DEFINITION HREF="e_tp_err.htm#type-error"><B>type-error</B></A>. In <A REL=DEFINITION HREF="26_glo_u.htm#unsafe"><I>unsafe</I></A> <A REL=DEFINITION HREF="26_glo_c.htm#code"><I>code</I></A>, the consequences are undefined. <P>
|
|
Typically, the ``should be prepared to signal'' terminology is used in type checking situations where there are efficiency considerations that make it impractical to detect errors that are not relevant to the correct operation of the <A REL=DEFINITION HREF="26_glo_o.htm#operator"><I>operator</I></A>. <P>
|
|
<DT><B>The consequences are unspecified</B> <P><DD>
|
|
This means that the consequences are unpredictable but harmless. Implementations are permitted to specify the consequences of this situation. No <A REL=DEFINITION HREF="26_glo_c.htm#conforming_code"><I>conforming code</I></A> may depend on the results or effects of this situation, and all <A REL=DEFINITION HREF="26_glo_c.htm#conforming_code"><I>conforming code</I></A> is required to treat the results and effects of this situation as unpredictable but harmless. For example, ``if the second argument to <A REL=DEFINITION HREF="f_shared.htm#shared-initialize"><B>shared-initialize</B></A> specifies a name that does not correspond to any <A REL=DEFINITION HREF="26_glo_s.htm#slot"><I>slots</I></A> <A REL=DEFINITION HREF="26_glo_a.htm#accessible"><I>accessible</I></A> in the <A REL=DEFINITION HREF="26_glo_o.htm#object"><I>object</I></A>, the results are unspecified.'' <P>
|
|
<DT><B>The consequences are undefined</B> <P><DD>
|
|
This means that the consequences are unpredictable. The consequences may range from harmless to fatal. No <A REL=DEFINITION HREF="26_glo_c.htm#conforming_code"><I>conforming code</I></A> may depend on the results or effects. <A REL=DEFINITION HREF="26_glo_c.htm#conforming_code"><I>Conforming code</I></A> must treat the consequences as unpredictable. In places where the words ``must,'' ``must not,'' or ``may not'' are used, then ``the consequences are undefined'' if the stated requirement is not met and no specific consequence is explicitly stated. An implementation is permitted to signal an error in this case. <P>
|
|
For example: ``Once a name has been declared by <A REL=DEFINITION HREF="m_defcon.htm#defconstant"><B>defconstant</B></A> to be constant, any further assignment or binding of that variable has undefined consequences.'' <P>
|
|
<DT><B>An error might be signaled</B> <P><DD>
|
|
This means that the situation has undefined consequences; however, if an error is signaled, it is of the specified <A REL=DEFINITION HREF="26_glo_t.htm#type"><I>type</I></A>. For example, ``<A REL=DEFINITION HREF="f_open.htm#open"><B>open</B></A> might signal an error of <A REL=DEFINITION HREF="26_glo_t.htm#type"><I>type</I></A> <A REL=DEFINITION HREF="e_file_e.htm#file-error"><B>file-error</B></A>.'' <P>
|
|
<DT><B>The return values are unspecified</B> <P><DD>
|
|
This means that only the number and nature of the return values of a <A REL=DEFINITION HREF="26_glo_f.htm#form"><I>form</I></A> are not specified. However, the issue of whether or not any side-effects or transfer of control occurs is still well-specified. <P>
|
|
A program can be well-specified even if it uses a function whose returns values are unspecified. For example, even if the return values of some function <TT>F</TT> are unspecified, an expression such as <TT>(length (list (F)))</TT> is still well-specified because it does not rely on any particular aspect of the value or values returned by <TT>F</TT>. <P>
|
|
<DT><B>Implementations may be extended to cover this situation</B> <P><DD>
|
|
This means that the <A REL=DEFINITION HREF="26_glo_s.htm#situation"><I>situation</I></A> has undefined consequences; however, a <A REL=DEFINITION HREF="26_glo_c.htm#conforming_implementation"><I>conforming implementation</I></A> is free to treat the situation in a more specific way. For example, an <A REL=DEFINITION HREF="26_glo_i.htm#implementation"><I>implementation</I></A> might define that an error is signaled, or that an error should be signaled, or even that a certain well-defined non-error behavior occurs. <P>
|
|
No <A REL=DEFINITION HREF="26_glo_c.htm#conforming_code"><I>conforming code</I></A> may depend on the consequences of such a <A REL=DEFINITION HREF="26_glo_s.htm#situation"><I>situation</I></A>; all <A REL=DEFINITION HREF="26_glo_c.htm#conforming_code"><I>conforming code</I></A> must treat the consequences of the situation as undefined. <A REL=DEFINITION HREF="26_glo_i.htm#implementation"><I>Implementations</I></A> are required to document how the situation is treated. <P>
|
|
For example, ``implementations may be extended to define other type specifiers to have a corresponding <A REL=DEFINITION HREF="26_glo_c.htm#class"><I>class</I></A>.'' <P>
|
|
<DT><B>Implementations are free to extend the syntax</B> <P><DD>
|
|
This means that in this situation implementations are permitted to define unambiguous extensions to the syntax of the <A REL=DEFINITION HREF="26_glo_f.htm#form"><I>form</I></A> being described. No <A REL=DEFINITION HREF="26_glo_c.htm#conforming_code"><I>conforming code</I></A> may depend on this extension. Implementations are required to document each such extension. All <A REL=DEFINITION HREF="26_glo_c.htm#conforming_code"><I>conforming code</I></A> is required to treat the syntax as meaningless. The standard might disallow certain extensions while allowing others. For example, ``no implementation is free to extend the syntax of <A REL=DEFINITION HREF="m_defcla.htm#defclass"><B>defclass</B></A>.'' <P>
|
|
<DT><B>A warning might be issued</B> <P><DD>
|
|
This means that <A REL=DEFINITION HREF="26_glo_i.htm#implementation"><I>implementations</I></A> are encouraged to issue a warning if the context is appropriate (e.g., when compiling). However, a <A REL=DEFINITION HREF="26_glo_c.htm#conforming_implementation"><I>conforming implementation</I></A> is not required to issue a warning. <P>
|
|
<P></DL><P>
|
|
<P><HR>The following <A REL=META HREF="../Front/X3J13Iss.htm">X3J13 cleanup issue</A>, <I>not part of the specification</I>, applies to this section:<P><UL><LI> <A REL=CHILD HREF="../Issues/iss144.htm">ERROR-TERMINOLOGY-WARNING:MIGHT</A><P></UL><HR>
|
|
|
|
<A REL=NAVIGATOR HREF="../Front/StartPts.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Starting Points]" SRC="../Graphics/StartPts.gif" ALIGN=Bottom></A><A REL=TOC HREF="../Front/Contents.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Contents]" SRC="../Graphics/Contents.gif" ALIGN=Bottom></A><A REL=INDEX HREF="../Front/X_Master.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Index]" SRC="../Graphics/Index.gif" ALIGN=Bottom></A><A REL=INDEX HREF="../Front/X_Symbol.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Symbols]" SRC="../Graphics/Symbols.gif" ALIGN=Bottom></A><A REL=GLOSSARY HREF="../Body/26_a.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Glossary]" SRC="../Graphics/Glossary.gif" ALIGN=Bottom></A><A HREF="../Front/X3J13Iss.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Issues]" SRC="../Graphics/Issues.gif" ALIGN=Bottom></A><BR>
|
|
|
|
<A REL=COPYRIGHT HREF="../Front/Help.htm#Legal"><I>Copyright 1996-2005, LispWorks Ltd. All rights reserved.</I></A><P>
|
|
</BODY>
|
|
</HTML>
|