📄 11.doc.html
字号:
<html>
<head>
<title>The Java Language Specification Exceptions</title>
</head>
<body BGCOLOR=#eeeeff text=#000000 LINK=#0000ff VLINK=#000077 ALINK=#ff0000>
<a href="index.html">Contents</a> | <a href="10.doc.html">Prev</a> | <a href="12.doc.html">Next</a> | <a href="j.index.doc1.html">Index</a>
<hr><br>
<a name="44043"></a>
<p><strong>
CHAPTER 11 </strong></p>
<a name="44044"></a>
<h1>Exceptions</h1>
<hr><p>
<a name="44046"></a>
When a Java program violates the semantic constraints of the Java language, a
Java Virtual Machine signals this error to the program as an <i>exception</i>. An example
of such a violation is an attempt to index outside the bounds of an array. Some
programming languages and their implementations react to such errors by
peremptorily terminating the program; other programming languages allow an
implementation to react in an arbitrary or unpredictable way. Neither of these
approaches is compatible with the design goals of Java: to provide portability and
robustness. Instead, Java specifies that an exception will be thrown when semantic
constraints are violated and will cause a non-local transfer of control from the
point where the exception occurred to a point that can be specified by the programmer.
An exception is said to be <i>thrown</i> from the point where it occurred and
is said to be <i>caught</i> at the point to which control is transferred.
<p><a name="44047"></a>
Java programs can also throw exceptions explicitly, using <code>throw</code> statements <a href="14.doc.html#237350">(§14.16)</a>. This provides an alternative to the old-fashioned style of handling error conditions by returning funny values, such as the integer value <code>-1</code> where a negative value would not normally be expected. Experience shows that too often such funny values are ignored or not checked for by callers, leading to programs that are not robust, exhibit undesirable behavior, or both.<p>
<a name="44051"></a>
Every exception is represented by an instance of the class <code>Throwable</code> or one of its subclasses; such an object can be used to carry information from the point at which an exception occurs to the handler that catches it. Handlers are established by <code>catch</code> clauses of <code>try</code> statements <a href="14.doc.html#79311">(§14.18)</a>. During the process of throwing an exception, a Java Virtual Machine abruptly completes, one by one, any expressions, statements, method and constructor invocations, static initializers, and field initialization expressions that have begun but not completed execution in the current thread. This process continues until a handler is found that indicates that it handles that particular exception by naming the class of the exception or a superclass of the class of the exception. If no such handler is found, then the method <code>uncaughtException</code> <a href="javalang.doc19.html#2901">(§20.21.31)</a> is invoked for the <code>ThreadGroup</code> that is the parent of the current thread-thus every effort is made to avoid letting an exception go unhandled.<p>
<a name="44058"></a>
The Java exception mechanism is integrated with the Java synchronization model <a href="17.doc.html#26250">(§17)</a>, so that locks are released as <code>synchronized</code> statements <a href="14.doc.html#79287">(§14.17)</a> and invocations of <code>synchronized</code> methods (<a href="8.doc.html#55408">§8.4.3.5</a>, <a href="15.doc.html#20448">§15.11</a>) complete abruptly.<p>
<a name="44074"></a>
This chapter describes the different causes of exceptions <a href="11.doc.html#44088">(§11.1)</a>. It details how exceptions are checked at compile time <a href="11.doc.html#44121">(§11.2)</a> and processed at run time <a href="11.doc.html#44153">(§11.3)</a>. A detailed example <a href="11.doc.html#44218">(§11.4)</a> is then followed by an explanation of the exception hierarchy and the standard exception classes <a href="11.doc.html#44278">(§11.5)</a>.<p>
<a name="44088"></a>
<h2>11.1 The Causes of Exceptions</h2>
<a name="44091"></a>
An exception is thrown for one of three <i>reasons</i>:
<p><ul><a name="44092"></a>
<li>An abnormal execution condition was synchronously detected by a Java Virtual Machine. Such conditions arise because:
<ul>
<a name="44093"></a>
<li>evaluation of an expression violates the normal semantics of the Java language, such as an integer divide by zero, as summarized in <a href="15.doc.html#79448">§15.5</a>
<a name="44106"></a>
<li>an error occurs in loading or linking part of the Java program (<a href="12.doc.html#44459">§12.2</a>, <a href="12.doc.html#44487">§12.3</a>)
<a name="44107"></a>
<li>some limitation a resource is exceeded, such as using too much memory
</ul>
</ul><ul><a name="44108"></a>
<br><br>These exceptions are not thrown at an arbitrary point in the program, but rather at a point where they are specified as a possible result of an expression evaluation or statement execution.
</ul><ul><a name="44112"></a>
<li>A <code>throw</code> statement <a href="14.doc.html#237350">(§14.16)</a> was executed in Java code.
<a name="44113"></a>
<li>An asynchronous exception occurred either because:
<ul>
<a name="44114"></a>
<li>the method <code>stop</code> of class <code>Thread</code> <a href="javalang.doc18.html#8096">(§20.20.16)</a> was invoked
<a name="44118"></a>
<li>an internal error has occurred in the virtual machine <a href="11.doc.html#44395">(§11.5.2.2)</a>
</ul>
</ul><a name="44119"></a>
Exceptions are represented by instances of the class <code>Throwable</code> and instances of its subclasses. These classes are, collectively, the <i>exception classes</i>.<p>
<a name="44121"></a>
<h2>11.2 Compile-Time Checking of Exceptions</h2>
<a name="44122"></a>
The Java language checks, at compile time, that a Java program contains handlers
for <i>checked exceptions</i>, by analyzing which checked exceptions can result from
execution of a method or constructor. For each checked exception which is a possible
result, the <code>throws</code> clause for the method <a href="8.doc.html#78323">(§8.4.4)</a> or constructor <a href="8.doc.html#244611">(§8.6.4)</a>
must mention the class of that exception or one of the superclasses of the class of
that exception. This compile-time checking for the presence of exception handlers
is designed to reduce the number of exceptions which are not properly handled.
<p><a name="44129"></a>
The <i>unchecked exceptions classes</i> are the class <code>RuntimeException</code> and its subclasses, and the class <code>Error</code> and its subclasses. All other exception classes are <i>checked exception classes</i>. The standard Java API defines a number of exception classes, both checked and unchecked. Additional exception classes, both checked and unchecked, may be declared by Java programmers. See <a href="11.doc.html#44278">§11.5</a> for a description of the Java exception class hierarchy and the exception classes defined by the standard Java API and Java Virtual Machine.<p>
<a name="44133"></a>
The checked exception classes named in the <code>throws</code> clause are part of the contract between the implementor and user of the method or constructor. The <code>throws</code> clause of an overriding method may not specify that this method will result in throwing any checked exception which the overridden method is not permitted, by its <code>throws</code> clause, to throw. When interfaces are involved, more than one method declaration may be overridden by a single overriding declaration. In this case, the overriding declaration must have a <code>throws</code> clause that is compatible with <i>all</i> the overridden declarations <a href="9.doc.html#78651">(§9.4)</a>.<p>
<a name="44146"></a>
Variable initializers for fields <a href="8.doc.html#24510">(§8.3.2)</a> and static initializers <a href="8.doc.html#39245">(§8.5)</a> must not result in a checked exception; if one does, a compile-time error occurs.<p>
<a name="44147"></a>
<h3>11.2.1 Why Errors are Not Checked</h3>
<a name="44148"></a>
Those unchecked exception classes which are the <i>error classes</i> (<code>Error</code> and its
subclasses) are exempted from compile-time checking because they can occur at
many points in the program and recovery from them is difficult or impossible. A
Java program declaring such exceptions would be cluttered, pointlessly.
<p><a name="44149"></a>
<h3>11.2.2 Why Runtime Exceptions are Not Checked</h3>
<a name="44150"></a>
The <i>runtime exception classes</i> (<code>RuntimeException</code> and its subclasses) are
exempted from compile-time checking because, in the judgment of the designers
of Java, having to declare such exceptions would not aid significantly in establishing
the correctness of Java programs. Many of the operations and constructs of the
Java language can result in runtime exceptions. The information available to a
Java compiler, and the level of analysis the compiler performs, are usually not sufficient
to establish that such runtime exceptions cannot occur, even though this
may be obvious to the Java programmer. Requiring such exception classes to be
declared would simply be an irritation to Java programmers.
<p><a name="44151"></a>
For example, certain code might implement a circular data structure that, by construction, can never involve <code>null</code> references; the programmer can then be certain  that a <code>NullPointerException</code> cannot occur, but it would be difficult for a compiler to prove it. The theorem-proving technology that is needed to establish such global properties of data structures is beyond the scope of this Java Language Specification.<p>
<a name="44153"></a>
<h2>11.3 Handling of an Exception</h2>
<a name="44154"></a>
When an exception is thrown, control is transferred from the code that caused the
exception to the nearest dynamically-enclosing <code>catch</code> clause of a <code>try</code> statement
<a href="14.doc.html#79311">(§14.18)</a> that handles the exception.
<p><a name="44158"></a>
A statement or expression is <i>dynamically enclosed</i> by a <code>catch</code> clause if it appears within the <code>try</code> block of the <code>try</code> statement of which the <code>catch</code> clause is a part, or if the caller of the statement or expression is dynamically enclosed by the <code>catch</code> clause.<p>
<a name="44159"></a>
The <i>caller</i> of a statement or expression depends on where it occurs:<p>
<ul><a name="44160"></a>
<li>If within a method, then the caller is the method invocation expression <a href="15.doc.html#20448">(§15.11)</a> that was executed to cause the method to be invoked.
<a name="44164"></a>
<li>If within a constructor or the initializer for an instance variable, then the caller is the class instance creation expression <a href="15.doc.html#41147">(§15.8)</a> or the method invocation of <code>newInstance</code> that was executed to cause an object to be created.
<a name="44168"></a>
<li>If within a static initializer or an initializer for a <code>static</code> variable, then the caller is the expression that used the class or interface so as to cause it to be initialized.
</ul><a name="44169"></a>
Whether a particular <code>catch</code> clause <i>handles</i> an exception is determined by comparing the class of the object that was thrown to the declared type of the parameter of the <code>catch</code> clause. The <code>catch</code> clause handles the exception if the type of its parameter is the class of the exception or a superclass of the class of the exception. Equivalently, a <code>catch</code> clause will catch any exception object that is an <code>instanceof</code> <a href="15.doc.html#80289">(§15.19.2)</a> the declared parameter type.<p>
<a name="44173"></a>
The control transfer that occurs when an exception is thrown causes abrupt completion of expressions <a href="15.doc.html#79448">(§15.5)</a> and statements <a href="14.doc.html#5894">(§14.1)</a> until a <code>catch</code> clause is encountered that can handle the exception; execution then continues by executing the block of that <code>catch</code> clause. The code that caused the exception is never resumed.<p>
<a name="44180"></a>
If no <code>catch</code> clause handling an exception can be found, then the current thread (the thread that encountered the exception) is terminated, but only after all <code>finally</code> clauses have been executed and the method <code>uncaughtException</code> <a href="javalang.doc19.html#2901">(§20.21.31)</a> has been invoked for the <code>ThreadGroup</code> that is the parent of the current thread.<p>
<a name="44184"></a>
In situations where it is desirable to ensure that one block of code is always executed after another, even if that other block of code completes abruptly, a <code>try</code> statement with a <code>finally</code> clause <a href="14.doc.html#236653">(§14.18.2)</a> may be used. If a <code>try</code> or <code>catch</code> block in a <code>try</code>-<code>finally</code> or <code>try</code>-<code>catch</code>-<code>finally</code> statement completes abruptly, then the <code>finally</code> clause is executed during propagation of the exception, even if no matching <code>catch</code> clause is ultimately found. If a <code>finally</code> clause is executed because of abrupt completion of a <code>try</code> block and the <code>finally</code> clause itself completes abruptly, then the reason for the abrupt completion of the <code>try</code> block is discarded and the new reason for abrupt completion is propagated from there.<p>
<a name="44188"></a>
The exact rules for abrupt completion and for the catching of exceptions are specified in detail with the specification of each statement in <a href="14.doc.html#44383">§14</a> and for expressions in <a href="15.doc.html#4709">§15</a> (especially <a href="15.doc.html#79448">§15.5</a>).<p>
<a name="44199"></a>
<h3>11.3.1 Exceptions are Precise</h3>
<a name="44200"></a>
Exceptions in Java are <i>precise</i>: when the transfer of control takes place, all effects
of the statements executed and expressions evaluated before the point from which
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -