Java conventions for exceptions

Discussion in 'Java' started by conrad, Mar 10, 2008.

  1. conrad

    conrad Guest

    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?

    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.

    Any insight appreciated.

    --
    conrad
     
    conrad, Mar 10, 2008
    #1
    1. Advertising

  2. conrad

    Lew Guest

    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
     
    Lew, Mar 10, 2008
    #2
    1. Advertising

  3. conrad

    conrad Guest

    On Mar 10, 6:54 pm, Lew <> wrote:
    > 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.
    >


    How do you force java to run a class file
    from a specific directory? If I have:

    Class foo = MyClass.class.getClass();
    InputStream baz = foo.getResourceAsStream("myfile.txt");

    baz is null at this point.

    How can this be remedied?

    Example: In C it is very simple.
    ..
    FILE *fp = fopen("myfile.txt", "r");
    ..
    As long as myfile.txt resides in
    the same directory as my C file,
    I can compile and run it just fine.

    I have the class variable using the directory
    that my class file and text file is located in.
    Yet getResourceAsStream returns null.

    --
    conrad
     
    conrad, Mar 11, 2008
    #3
  4. conrad

    Lew Guest

    conrad wrote:
    > I have the class variable using the directory
    > that my class file and text file is located in.
    > Yet getResourceAsStream returns null.


    Did you check out the Javadocs?

    Each of the three classes that have a getResource() / getResourceAsStream()
    resolve paths a little differently, and somewhat non-obviously in the case of
    javax.servlet.ServletContext.

    Let's just focus on Class's:
    <http://java.sun.com/javase/6/docs/api/java/lang/Class.html#getResourceAsStream(java.lang.String)>
    > The rules for searching resources associated with a given class are
    > implemented by the defining class loader of the class.

    ....
    > Before delegation, an absolute resource name is constructed
    > from the given resource name using this algorithm:
    >
    > * If the name begins with a '/' ('\u002f'), then the absolute name
    > of the resource is the portion of the name following the '/'.
    > * Otherwise, the absolute name is of the following form:
    >
    > modified_package_name/name
    >
    >
    > Where the modified_package_name is the package name of this object
    > with '/' substituted for '.' ('\u002e').


    So what is "this object"? It is the class that invokes getResourceAsStream().
    The package name is that of the class whose Class object we're using.

    > Class foo = MyClass.class.getClass();
    > InputStream baz = foo.getResourceAsStream("myfile.txt");


    In this case the class whose Class object we're using is 'class' from
    'MyClass'. That object is of type java.lang.Class. It will look based on a
    package name of 'java.lang'.

    Actually, this class object is of type Class < Class < MyClass >>. You really
    should have used generics here! (Also, name your class something that doesn't
    have the word "Class" in it.)

    So the package name is taken from java.lang.Class, not your.package.My. Hence
    "myfile.txt" would have to be in a subdirectory "java/lang/" of a classpath
    element, and that ain't gonna happen.

    You want 'foo' to be of type Class <My>, not Class <Class <My>>.

    InputStream baz = My.class.getResourceAsStream( "myfile.txt" );

    --
    Lew
     
    Lew, Mar 11, 2008
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Ahmed Moustafa
    Replies:
    5
    Views:
    30,098
    Chris Smith
    Jul 14, 2004
  2. The Abrasive Sponge
    Replies:
    2
    Views:
    355
    Frank
    Oct 11, 2004
  3. Paul Miller
    Replies:
    3
    Views:
    1,047
    Alex Martelli
    Nov 12, 2003
  4. Replies:
    3
    Views:
    630
    Sherm Pendley
    Apr 16, 2007
  5. Lie
    Replies:
    3
    Views:
    699
Loading...

Share This Page