Re: Java conventions for exceptions
conrad wrote:
I was reading through the tutorials on java.sun
and it was stressed that the call of the method
close(in their example) should occur in
the finally block. So I followed this convention
but the only difference is that I am using a
BufferedReader object. Now I forego calling
close method for this object in the try block
and instead do it in the finally block. But it
doesn't seem to like this as it wants me to
catch IOException, which I am already catching
anyhow due to the use of BufferedReader.
Why the inconsistency here?
There is no inconsistency.
Classes do not throw exceptions; methods do. You are not "already catching
anyhow" the IOException from the close() call.
The close() method can throw an exception. You're not in the original 'try'
block, so the 'finally' block in which the close() exists does not have a
'catch'. You need to put the close() in its own, nested try-catch.
And while I'm at it, what is the best idea
with respect to opening some file
in windows? I've read two competing
camps. Those that say to use relative paths
and those that say to use absolute paths.
I've tried using relative paths but it is
useless if my program doesn't know what
directory to look into(I'm assuming there
is some environment variable that must be
altered?). I have the class file in the same
directory as my txt file, using FileReader
and passing the result to the constructor
for BufferedReader.
Use Class or ClassLoader getResource() or getResourceAsStream(). That will
open resources relative to the application's classpath. You should not use
absolute paths because in general that kills portability of the application,
not only between OSes but between different machines even if they use the same OS.
In other words, absolute paths are "useless if [your] program doesn't know
what directory" even exists on the target platform.
Since you are storing your resource in the class path anyway, the
getResource[...]() methods are for you.
--
Lew