📄 tij0098.html
字号:
<html><body>
<table width="100%"><tr>
<td>
<a href="http://www.bruceeckel.com/javabook.html">Bruce Eckel's Thinking in Java</a>
</td>
<td align="right">
<a href="tij_c.html">Contents</a> | <a href="tij0097.html">Prev</a> | <a href="tij0099.html">Next</a>
</td>
</tr></table>
<hr>
<H2 ALIGN=LEFT>
Catching
an exception
<P><A NAME="Index910"></A><A NAME="Index911"></A></H2>
<DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">If
a method throws an exception, it must assume that exception is caught and dealt
with. One of the advantages of Java exception handling is that it allows you to
concentrate on the problem you’re trying to solve in one place, and then
deal with the errors from that code in another place.
</FONT><P></DIV><DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">To
see how an exception is caught, you must first understand the concept of a <A NAME="Index912"></A><A NAME="Index913"></A></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><I>guarded
region
</I></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">,
which is a section of code that might produce exceptions, and is followed by
the code to handle those exceptions.
</FONT><a name="_Toc312374114"></a><a name="_Toc375545365"></a><a name="_Toc408018592"></a><P></DIV>
<A NAME="Heading285"></A><H3 ALIGN=LEFT>
The
try block
</H3>
<DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">If
you’re inside a method and you throw an exception (or another method you
call within this method throws an exception), that method will exit in the
process of throwing. If you don’t want a
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>throw
</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">to
leave a method, you can set up a special block within that method to capture
the exception. This is called the
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><I>try</I></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><I>block<A NAME="Index914"></A><A NAME="Index915"></A></I></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
because you “try” your various method calls there. The try block is
an ordinary scope, preceded by the keyword
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>try</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">:</FONT><P></DIV>
<font color="#990000"><PRE><font color="#0000ff">try</font> {
<font color="#009900">// Code that might generate exceptions</font>
}</PRE></font><DIV ALIGN=LEFT><P></DIV><DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">If
you were checking for errors carefully in a programming language that
didn’t support exception handling, you’d have to surround every
method call with setup and error testing code, even if you call the same method
several times. With exception handling, you put everything in a try block and
capture all the exceptions in one place. This means your code is a lot easier
to write and easier to read because the goal of the code is not confused with
the error checking.
</FONT><a name="_Toc312374115"></a><a name="_Toc375545366"></a><a name="_Toc408018593"></a><P></DIV>
<A NAME="Heading286"></A><H3 ALIGN=LEFT>
Exception
handlers
</H3>
<DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">Of
course, the thrown exception must end up someplace. This “place” is
the
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><I>exception
handler<A NAME="Index916"></A><A NAME="Index917"></A></I></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">,
and there’s one for every exception type you want to catch. Exception
handlers immediately follow the try block and are denoted by the keyword
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>catch<A NAME="Index918"></A></B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">:</FONT><P></DIV>
<font color="#990000"><PRE><font color="#0000ff">try</font> {
<font color="#009900">// Code that might generate exceptions</font>
} <font color="#0000ff">catch</font>(Type1 id1) {
<font color="#009900">// Handle exceptions of Type1</font>
} <font color="#0000ff">catch</font>(Type2 id2) {
<font color="#009900">// Handle exceptions of Type2</font>
} <font color="#0000ff">catch</font>(Type3 id3) {
<font color="#009900">// Handle exceptions of Type3</font>
}
<font color="#009900">// etc... </PRE></font></font><DIV ALIGN=LEFT><P></DIV><DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">Each
catch clause (exception handler) is like a little method that takes one and
only one argument of a particular type. The identifier (
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>id1</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">,
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>id2</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">,
and so on) can be used inside the handler, just like a method argument.
Sometimes you never use the identifier because the type of the exception gives
you enough information to deal with the exception, but the identifier must
still be there.
</FONT><P></DIV><DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">The
handlers must appear directly after the try block. If an exception is thrown,
the exception-handling mechanism goes hunting for the first handler with an
argument that matches the type of the exception. Then it enters that catch
clause, and the exception is considered handled. (The search for handlers stops
once the catch clause is finished.) Only the matching catch clause executes;
it’s not like a
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>switch</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
statement in which you need a
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>break</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
after each
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>case</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
to prevent the remaining ones from executing.
</FONT><P></DIV><DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">Note
that, within the try block, a number of different method calls might generate
the same exception, but you need only one handler.
</FONT><P></DIV>
<A NAME="Heading287"></A><H4 ALIGN=LEFT>
Termination
vs. resumption
<P><A NAME="Index919"></A><A NAME="Index920"></A><A NAME="Index921"></A></H4>
<DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">There
are two basic models in exception-handling theory. In
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><I>termination</I></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
(which is what Java and C++ support), you assume the error is so critical
there’s no way to get back to where the exception occurred. Whoever threw
the exception decided that there was no way to salvage the situation, and they
don’t
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><I>want</I></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
to come back.
</FONT><P></DIV><DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">The
alternative is called
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><I>resumption</I></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">.
It means that the exception handler is expected to do something to rectify the
situation, and then the faulting method is retried, presuming success the
second time. If you want resumption, it means you still hope to continue
execution after the exception is handled. In this case, your exception is more
like a method call – which is how you should set up situations in Java in
which you want resumption-like behavior. (That is, don’t throw an
exception; call a method that fixes the problem.) Alternatively, place your
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>try</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
block inside a
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>while</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
loop that keeps reentering the
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>try</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
block until the result is satisfactory.
</FONT><P></DIV><DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">Historically,
programmers using operating systems that supported resumptive exception
handling eventually ended up using termination-like code and skipping
resumption. So although resumption sounds attractive at first, it seems it
isn’t quite so useful in practice. The dominant reason is probably the <A NAME="Index922"></A></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><I>coupling
</I></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">that
results: your handler must often be aware of where the exception is thrown from
and contain non-generic code specific to the throwing location. This makes the
code difficult to write and maintain, especially for large systems where the
exception can be generated from many points.
</FONT><a name="_Toc312374116"></a><a name="_Toc375545367"></a><a name="_Toc408018594"></a><P></DIV>
<A NAME="Heading288"></A><H3 ALIGN=LEFT>
The
exception specification
<P><A NAME="Index923"></A><A NAME="Index924"></A></H3>
<DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">In
Java, you’re required to inform the client programmer, who calls your
method, of the exceptions that might be thrown from your method. This is
civilized because the caller can know exactly what code to write to catch all
potential exceptions. Of course, if source code is available, the client
programmer could hunt through and look for
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>throw</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
statements, but often a library doesn’t come with sources. To prevent
this from being a problem, Java provides syntax (and
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><I>forces
</I></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">you
to use that syntax) to allow you to politely tell the client programmer what
exceptions this method throws, so the client programmer can handle them. This
is the
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><I>exception
specification
</I></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
and it’s part of the method declaration, appearing after the argument list.
</FONT><P></DIV><DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">The
exception specification uses an additional keyword,
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>throws</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">,
followed by a list of all the potential exception types. So your method
definition might look like this:
</FONT><P></DIV><DIV ALIGN=LEFT><TT><FONT FACE="Courier New" SIZE=3 COLOR="Black">void
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -