Why no close() method for the File object ?

Discussion in 'Java' started by me2, Nov 8, 2006.

  1. me2

    me2 Guest

    I am using the File object in an app.

    I noticed there is no close() method for it. Why not ? What am I missing ?

    Does Java just rely on the object going out of scope to close the file ?
    Or does one only have to close the stream associated with the file ?

    Thanks.
     
    me2, Nov 8, 2006
    #1
    1. Advertising

  2. me2

    Simon Brooke Guest

    in message <PZo4h.279972$5R2.63239@pd7urf3no>, me2 ('')
    wrote:

    > I am using the File object in an app.
    >
    > I noticed there is no close() method for it. Why not ? What am I
    > missing ?
    >
    > Does Java just rely on the object going out of scope to close the file ?
    > Or does one only have to close the stream associated with the file ?


    You don't close the file, you close the stream.

    --
    (Simon Brooke) http://www.jasmine.org.uk/~simon/

    ;; Perl ... is the Brittney Spears of programming - easily accessible
    ;; but, in the final analysis, empty of any significant thought
    ;; Frank Adrian on Slashdot, 21st July 2003
     
    Simon Brooke, Nov 8, 2006
    #2
    1. Advertising

  3. me2 schrieb:
    > I am using the File object in an app.
    >
    > I noticed there is no close() method for it. Why not ? What am I missing ?


    You can't open a File object - so you can't close it.

    A File object is just "an abstract representation of file and directory
    pathnames" [API].

    >
    > Does Java just rely on the object going out of scope to close the file ?
    > Or does one only have to close the stream associated with the file ?


    There's no stream associated with a File object. But you can open
    streams by passing File objeocts to their cnstructors or methods
    respecutively. And, yes, yo've to close the stream.

    Bye
    Michael
     
    Michael Rauscher, Nov 8, 2006
    #3
  4. me2 wrote:
    > I am using the File object in an app.
    >
    > I noticed there is no close() method for it. Why not ? What am I missing ?


    It represents a file (really a file path). It does not represent an open
    file channel.

    > Does Java just rely on the object going out of scope to close the file ?
    > Or does one only have to close the stream associated with the file ?


    No. If you have a file *stream* then you make sure you always close it:

    public void write(File file) throws IOException {
    OutputStream rawOut = new FileOutputStream(file);
    try {
    BufferedOutputStream out = new BufferedOutputStream(rawOut);
    out.write(42);
    ...
    out.flush();
    } finally {
    rawOut.close();
    }
    }

    Note, it's important to flush the buffered output in the happy case.
    BufferedOutputStream.close is broken.

    Tom Hawtin
     
    Thomas Hawtin, Nov 8, 2006
    #4
  5. Michael Rauscher wrote:
    > me2 schrieb:
    >> I am using the File object in an app.
    >>
    >> I noticed there is no close() method for it. Why not ? What am I
    >> missing ?

    >
    > You can't open a File object - so you can't close it.
    >
    > A File object is just "an abstract representation of file and directory
    > pathnames" [API].
    >
    >>
    >> Does Java just rely on the object going out of scope to close the file
    >> ? Or does one only have to close the stream associated with the file ?

    >
    > There's no stream associated with a File object. But you can open
    > streams by passing File objeocts to their cnstructors or methods
    > respecutively. And, yes, yo've to close the stream.


    I think some confusion could have been avoided if it had been called
    "java.io.PathName" instead of "java.io.File".

    For example, the exists() method makes sense as an instance method,
    because there may not be any file matching the path name. The lack of
    open and close methods also makes more sense when you think of it as a
    path name rather than a file.

    Patricia
     
    Patricia Shanahan, Nov 8, 2006
    #5
  6. Patricia Shanahan schrieb:
    > I think some confusion could have been avoided if it had been called
    > "java.io.PathName" instead of "java.io.File".


    Right.

    Michael
     
    Michael Rauscher, Nov 8, 2006
    #6
  7. me2

    Chris Uppal Guest

    Thomas Hawtin wrote:

    > BufferedOutputStream.close is broken.


    It is ? How, and since when ? The version in 1.5 (actually inherited from
    FilterOutputStream) looks OK to me.

    -- chris
     
    Chris Uppal, Nov 8, 2006
    #7
  8. Chris Uppal wrote:
    > Thomas Hawtin wrote:
    >
    >> BufferedOutputStream.close is broken.

    >
    > It is ? How, and since when ? The version in 1.5 (actually inherited from
    > FilterOutputStream) looks OK to me.


    Ignoring an exception is almost always a mistake.

    public void close() throws IOException {
    try {
    flush();
    } catch (IOException ignored) {
    }
    out.close();
    }

    Suppose flush causes your file to exceed the disk capacity. An exception
    is thrown, but ignored. The stream is the closed normally and no
    exception is thrown.

    A better implementation would be:

    public void close() throws IOException {
    try {
    flush();
    } finally {
    out.close();
    }
    }

    Tom Hawtin
     
    Thomas Hawtin, Nov 8, 2006
    #8
  9. Thomas Hawtin wrote:
    > Chris Uppal wrote:
    >> Thomas Hawtin wrote:
    >>
    >>> BufferedOutputStream.close is broken.

    >>
    >> It is ? How, and since when ? The version in 1.5 (actually inherited
    >> from
    >> FilterOutputStream) looks OK to me.


    > A better implementation would be:


    See Bug 6390383

    http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6390383

    (It' me with the first comment. I don't think the tickbox survives
    indirection through the Sun Online thingy login page.)

    Tom Hawtin
     
    Thomas Hawtin, Nov 8, 2006
    #9
  10. me2

    Chris Uppal Guest

    Thomas Hawtin wrote:

    > > > BufferedOutputStream.close is broken.

    > >
    > > It is ? How, and since when ? The version in 1.5 (actually inherited
    > > from FilterOutputStream) looks OK to me.

    >
    > Ignoring an exception is almost always a mistake. [...]


    Ah, I see what you mean -- I was expecting to see broken buffering code. I
    agree that the empty exception handler is just silly.

    -- chris
     
    Chris Uppal, Nov 9, 2006
    #10
    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. Daniel Albisser
    Replies:
    1
    Views:
    1,155
    GaryM
    Apr 7, 2004
  2. Paul van Rossem
    Replies:
    0
    Views:
    624
    Paul van Rossem
    Apr 7, 2005
  3. Mr. SweatyFinger
    Replies:
    2
    Views:
    2,258
    Smokey Grindel
    Dec 2, 2006
  4. Xiao Ma
    Replies:
    16
    Views:
    1,522
    =?ISO-8859-15?Q?Arne_Vajh=F8j?=
    Oct 27, 2007
  5. Iñaki Baz Castillo
    Replies:
    7
    Views:
    948
    Iñaki Baz Castillo
    Jan 12, 2010
Loading...

Share This Page