Can I omit try-catch?-CodePudding

I want to fetch an HTML page and read in with BufferedReader. So I use try-with-resources to open it handles IOException this way:

try(BufferedReader reader = new BufferedReader(new InputStreamReader(url.openStream()))) {
        
    } catch(IOException e) {
        throw e;
    }

Is this a good pattern to catch and instantly throw? And what if I omit try at all and state that function throws IOException? If then any potentional memory leak? Much appreciate any advice!

CodePudding user response：

A catch block is not required in a try-with-resources statement. You could write the following, which would mean exactly the same as your original code:

try (BufferedReader reader = new BufferedReader(
        new InputStreamReader(url.openStream()))) {
    // do something
}

So, you can leave out the catch block, if all you ever do there is immediately throw the same exception again.

You do want the try block however, so that the BufferedReader and underlying stream(s) are automatically closed at the end of the block.

Is this a good pattern to catch and instantly throw?

No, catching and immediately re-throwing the same exception does not add anything useful.

CodePudding user response：

To add to @Jesper's excellent answer, you do want to include the try block so that the BufferedReader will be closed. If you don't do this, it'll eventually be garbage collected, so it isn't technically a resource leak in the sense that the resources would eventually be reclaimed; however, the "eventually" part is potentially problematic because there are no guarantees as to exactly when that'll happen. Thus, a bigger issue is whether this would create race conditions if it's using a resource that needs to be reused eventually.

I'm not very familiar with the implementation details of that exact class, so this is somewhat speculative, but one example of an issue you can run into with some classes that perform network calls if you fail to return resources to the operating system promptly is port exhaustion. By way of another example, if you are modifying a file, the file could remain locked until the GC happens to release the file lock.