Omitting the catch block

[nick woodward]

Just a quick question if any of you don't mind......!

What's the point of having no catch block when handling an exception? For example, having a try block paired with just a finally block.

You use the try block to run risky code - but without a catch block the compiler won't allow it anyway - doesn't that make the 'try' block a bit pointless? (other than being required!)

The only example i could think of is to allow you to mix and match the benefits of ducking an exception and running code in the finally block. Does that sound about right?

Thanks,

Nick

[Winston Gutkowski]

nick woodward wrote:The only example i could think of is to allow you to mix and match the benefits of ducking an exception and running code in the finally block. Does that sound about right?

Pretty much, although I'm not sure that "ducking" is quite the right term. If you don't specify a catch clause, whatever exception that would have been thrown will still be thrown, but the thing about a finally clause is that it will be executed even if an exception occurs.

HIH

Winston

[nick woodward]

yeah, sorry, i've just heard the word used before to describe not handling the exception in that specific method and allowing it to be passed up (down?) the stack.

anyway, thanks for the quick reply!

Nick

[Roel De Nijs]

nick woodward wrote:The only example i could think of is to allow you to mix and match the benefits of ducking an exception and running code in the finally block. Does that sound about right?

That sounds about right, although there are other examples as well

Probably an obvious is described in the following code snippet (prior to Java 7)

class Line {}
class Statistics {
    public void calculate(String file) {
        try {
            List<Line> list = readLines(file);
            // process list
        } catch (IOException e) {
            // handle exception
        }
    }
    
    private List<Line> readLines(String file) throws IOException {
        List<Line> list = new ArrayList<>();
        FileInputStream fis = null;
        try {
            // create input stream
            fis = new FileInputStream(file);
            // do risky I/O stuff
        } finally {
            if (fis != null) {
                fis.close();
            }
        }
        return list;
    }
}

If something went wrong while reading the file to create the list of lines in the readLines method, you don't want to process the lines because that's pretty useless. So the IOException is thrown from the readLines method and handled in the calculate method. But you definitely want to close all resources you have used. When using try-with-resources (Java 7 and later) the readLines method is more concise but the code is equivalent (the compiler will generate the appropriate finally block for you)

private List<Line> readLines(String file) throws IOException {
    List<Line> list = new ArrayList<>();
    try (FileInputStream fis = new FileInputStream(file)) {
        // do risky I/O stuff
    }
    return list;
}

Another example is when you are working with concurrency and locks. When you acquire a lock, you always want to release this lock once you are done. So all code that needs to be executed while the lock is held, will be executed inside a try-finally block and releasing the lock happens in the finally block. This way you are ensured the lock is always released when necessary

 Lock lock = ...;
 lock.lock();
 try {
   // access the resource protected by this lock
 } finally {
   lock.unlock();
 }

This idiom is even documented in the API documentation.

Hope it helps!
Kind regards,
Roel

Disclaimer: none of these topics (try-with-resources, file I/O, concurrency, and locks) are not a topic of the OCA certification exams. I used them for demonstration purposes only. So if you don't understand what's happening, don't worry and just move on! All these topics are an OCP exam objective.

[edit] Forgot to mention that try-with-resources and file I/O are also not on the OCA exam. Thanks Jeanne!

[Jeanne Boyarsky]

Reading a file isn't on the OCA either. Nor is any other use case I can think of where not having a catch block is wise.

Because of this, the exceptions questions you tend to see on the OCA exam tend to be contrived.

[Thakur Sachin Singh]

Nice explanation Roel De Nijs

[nick woodward]

it does indeed help Roel, thanks a lot!

Nick

[Winston Gutkowski]

Roel De Nijs wrote:Another example is when you are working with concurrency and locks...

Yeah! That's the example I was trying to remember. Have a cow for solving my Alzheimers.

Winston