tij0103.html

学习java的经典书籍

</FONT><P></DIV><DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">The
constructor for 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>InputFile</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
takes a 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>String</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
argument, which is the name of the file you want to open. Inside a 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>try</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
block, it creates a 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>FileReader</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
using the file name. A 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>FileReader</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
isn&#8217;t particularly useful until you turn around and use it to create a 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>BufferedReader</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
that you can actually talk to &#8211; notice that one of the benefits of 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>InputFile</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
is that it combines these two actions.
</FONT><P></DIV><DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">If
the 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>FileReader</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
constructor is unsuccessful, it throws a <A NAME="Index969"></A><A NAME="Index970"></A></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>FileNotFoundException</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">,
which must be caught separately because that&#8217;s the one case in which you
don&#8217;t want to close the file since it wasn&#8217;t successfully opened.
Any 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><I>other</I></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
catch clauses must close the file because it 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><I>was</I></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
opened by the time those catch clauses are entered. (Of course, this is
trickier if more than one method can throw a 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>FileNotFoundException</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">.
In that case, you might want to break things into several 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>try
</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">blocks.)
The 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>close(&#160;)</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
method throws an exception that is tried and caught even though it&#8217;s
within the block of another 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>catch</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
clause &#8211; it&#8217;s just another pair of curly braces to the Java
compiler. After performing local operations, the exception is re-thrown, which
is appropriate because this constructor failed, and you wouldn&#8217;t want the
calling method to assume that the object had been properly created and was valid.
</FONT><P></DIV><DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">In
this example, which doesn&#8217;t use the aforementioned flagging technique, the 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>finally</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
clause is definitely 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><I>not</I></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
the place to 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>close(&#160;)</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
the file, since that would close it every time the constructor completed. Since
we want the file to be open for the useful lifetime of the 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>InputFile</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
object this would not be appropriate.
</FONT><P></DIV><DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">The
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>getLine(&#160;)</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
method returns a 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>String</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
containing the next line in the file. It calls <A NAME="Index971"></A><A NAME="Index972"></A></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>readLine(&#160;),</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
which can throw an exception, but that exception is caught so 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>getLine(&#160;)</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
doesn&#8217;t throw any exceptions. One of the design issues with <A NAME="Index973"></A>exceptions
is whether to handle an exception completely at this level, to handle it
partially and pass the same exception (or a different one) on, or whether to
simply pass it on. Passing it on, when appropriate, can certainly simplify
coding. The 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>getLine(&#160;)</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
method becomes:
</FONT><P></DIV>

<font color="#990000"><PRE>String getLine() <font color="#0000ff">throws</font> IOException {
  <font color="#0000ff">return</font> in.readLine();
}</PRE></font><DIV ALIGN=LEFT><P></DIV><DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">But
of course, the caller is now responsible for handling any 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>IOException</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
that might arise.
</FONT><P></DIV><DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">The
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>cleanup(&#160;)</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
method must be called by the user when they are finished using the 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>InputFile</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
object to release the system resources (such as file handles) that are used by
the 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>BufferedReader</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
and/or 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>FileReader</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
objects.
</FONT><A NAME="fnB46" HREF="#fn46">[46]</A><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
You don&#8217;t want to do this until you&#8217;re finished with the 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>InputFile</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
object, at the point you&#8217;re going to let it go. You might think of
putting such functionality into a <A NAME="Index974"></A></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>finalize(&#160;)</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
method, but as mentioned in Chapter 4 you can&#8217;t always be sure that 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>finalize(&#160;)</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
will be called (even if you 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><I>can</I></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
be sure that it will be called, you don&#8217;t know 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><I>when</I></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">).
This is one of the downsides to Java &#8211; all cleanup other than memory
cleanup doesn&#8217;t happen automatically, so you must inform the client
programmer that they are responsible, and possibly guarantee that cleanup
occurs using 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>finalize(&#160;)</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">.</FONT><P></DIV><DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">In
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>Cleanup.java</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
an 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>InputFile</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
is created to open the same source file that creates the program, and this file
is read in a line at a time, and line numbers are added. All exceptions are
caught generically in 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>main(&#160;)</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">,
although you could choose greater granularity.
</FONT><P></DIV><DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">One
of the benefits of this example is to show you why exceptions are introduced at
this point in the book. Exceptions are so integral to programming in Java,
especially because the compiler enforces them, that you can accomplish only so
much without knowing how to work with them.
</FONT><a name="_Toc305593301"></a><a name="_Toc305628773"></a><a name="_Toc312374124"></a><a name="_Toc375545377"></a><a name="_Toc408018605"></a><P></DIV>
<HR><DIV ALIGN=LEFT><A NAME="fn46" HREF="#fnB46">[46]</A><FONT FACE="Carmina Md BT" SIZE=2 COLOR="Black">
In C++, a 
</FONT><FONT FACE="Carmina Md BT" SIZE=2 COLOR="Black"><I>destructor</I></FONT><FONT FACE="Carmina Md BT" SIZE=2 COLOR="Black">
would handle this for you.
</FONT><P></DIV>


<div align="right">
<a href="tij_c.html">Contents</a> | <a href="tij0102.html">Prev</a> | <a href="tij0104.html">Next</a>
</div>
</body></html>