Question

I’m writing an app that connect to a website and read one line from it. I do it like this:

try{
        URLConnection connection = new URL("www.example.com").openConnection();
        BufferedReader rd = new BufferedReader(new InputStreamReader(connection.getInputStream()));
        String response = rd.readLine();
        rd.close();
    }catch (Exception e) {
        //exception handling
    }

Is it good? I mean, I close the BufferedReader in the last line, but I do not close the InputStreamReader. Should I create a standalone InputStreamReader from the connection.getInputStream, and a BufferedReader from the standalone InputStreamReader, than close all the two readers?
I think it will be better to place the closing methods in the finally block like this:

InputStreamReader isr = null;
BufferedReader br = null;
try{
    URLConnection connection = new URL("www.example.com").openConnection();
    isr = new InputStreamReader(connection.getInputStream());
    br = new BufferedReader(isr);
    String response = br.readLine();
}catch (Exception e) {
    //exception handling
}finally{
    br.close();
    isr.close();
}

But it is ugly, because the closing methods can throw exception, so I have to handle or throw it.

Which solution is better? Or what would be the best solution?

Answer 1

The general idiom for resource acquisition and release in Java is:

final Resource resource = acquire();
try {
    use(resource);
} finally {
    resource.release();
}

Note:

• try should immediately follow the acquire. This means you can’t wrap it in the decorator and maintain safety (and removing spaces or putting things on one line doesn’t help:).
• One release per finally, otherwise it wont be exception safe.
• Avoid null, use final. Otherwise you’ll have messy code and potential for NPEs.
• Generally there is no need to close the decorator unless it has a further resource associated with it. However, you will generally need to flush outputs, but avoid that in the exception case.
• The exception should either be passed through to the caller, or caught from a surrounding try block (Java leads you astray here).

ou can abstract this nonsense with the Execute Around idiom, so you don’t have to repeat yourself (just write a lot of boilerplate).