tags:

views:

836

answers:

3
    public void exportUrlsToFile(String file, String urls) throws IOException {
 String[] urlsArray = urls.split("\\s+");// split on one or more white space characters.

 // create a fresh file
 RandomAccessFile raf = new RandomAccessFile(file, "rw");

 for (String line : urlsArray) {
  line = line.trim();
  if (line.isEmpty()) {// this won't happen!
   continue;
  }
  raf.writeBytes(line);
  raf.writeBytes(newline);
 }
 // close the file handler
 raf.close();
}

Basically I use this class to do something. This is part of application that is running inside tomcat JVM. I have noticed that anytime this method is called, it creates a file with the same name as the argument and after raf.close(), it is still there. How can I make sure that the temp file is removed.

Thanks in advance.

+1  A: 

Use File.createTempFile() instead?

I realize that won't give you the same features as RandomAccessFile but you could build what you need on top of that.

Actually I'm not even sure why you're writing these things to a file. Is this some kind of usage tracking thing? Why not just store it in memory?

cletus
This is a struts web app, in order for struts to download a file, you needs you to stream from a file. I always thought random access file is for in memory creation of a file without creating a physical one.
samsina
+2  A: 

I'm going to assume that you're showing only a small portion of the code and that there's a good reason that you're using RandomAccessFile when it doesn't appear that any random access is being done.

I would do something like this:

public void exportUrlsToFile(String file, String urls) throws IOException {
  String[] urlsArray = urls.split("\\s+");

  // create a fresh file
  RandomAccessFile raf = new RandomAccessFile(file, "rw");

  try {
    for (String line : urlsArray) {
      line = line.trim();
      if (line.isEmpty()) { // this won't happen!
        continue;
      }
      raf.writeBytes(line);
      raf.writeBytes(newline);
    }
  } finally {
    // don't leak file handles on Exception -- put close in "try/finally"
    try { raf.close(); } catch (IOException e) { /* ignore */ }
    File todelete = new File(file);
    if (!todelete.delete()) {
      // Log a complaint that we couldn't delete the temp file
    }
  }
}

EDIT: I agree, we don't want the theoretical IOException on close() to cause problem. Better than ignoring it would be to log a "We never expected to see this...." with the exception. I often create a closeWithoutException() method just to wrap this. Close theoretically throwing IOException seems an abuse of checked exceptions because there's nothing you can expect the caller to do in response.

Eddie
+4  A: 

A better question would be why you would want to go through all the trouble of making the file, writing things to the file, and then just delete the file?!

Regardless you don't need a random access file - a FileWriter would be better.

To ensure that the file is deleted do as Eddie suggests and put the delete in a finnaly block - but you will also need to ensure that the raf.close() IOException is handled... something like:

} finally {
    try
    {
        raf.close();
    }
    catch(final IOException ex)
    {
         // in 14 years of Java programming I still don't know what to do here! ;-)
    }
    finally
    {
        File todelete = new File(file);
        if (!todelete.delete()) {
            // Log a complaint that we couldn't delete the temp file
        }
    }
}

Edit:

You might also mean that after the Tomcat process finished the file is still there and you want it gone. If that is the case look at java.io.File.deleteOnExit(). That should delete the files when the Tomcat JVM exists.

TofuBeer
he he hehe ... most of the times, you do nothing there. ...
OscarRyz
in 14 years that is all I have ever done :-) (well log it... but seems pointless given it never happens!)
TofuBeer
I only system log it, on principle; I have never had a close throw an IOException either. It's one of the proofs against checked exceptions, methods that "throw" one because the interface declares it so, but which really don't.
Software Monkey
@Software Monkey: To me, it's not proof against checked exceptions, but it's an abuse of checked exceptions.
Eddie
I can imagine close throwing an exception - NFS goes away with an open file might cause it. Just in practice I have never ever heard of it happening.
TofuBeer