Proper sample catch design

Question

What would be considered a more appropriate technique for implementing try / catch in Java:

A:

Date lastMod = null; BufferedReader inFile = null; try { inFile = new BufferedReader(new FileReader("C:\\Java\\settings.ini")); try { lastMod = new Date(Long.parseLong(inFile.readLine())); } catch (IOException e) { e.printStackTrace(); } } catch(FileNotFoundException e) { e.printStackTrace(); } 

or B:

 Date lastMod = null; BufferedReader inFile = null; try { inFile = new BufferedReader(new FileReader("C:\\Java\\settings.ini")); lastMod = new Date(Long.parseLong(inFile.readLine())); } catch (FileNotFoundException e) { e.printStackTrace(); } catch (IOException e) { e.printStackTrace(); } 

Also, is it wrong to follow a try / catch block with a long block of code that BufferedReader uses, or prefers to include a long block of code inside try / catch?

For instance:

 public static void main(String[] args) { Date lastMod = null; BufferedReader inFile = null; try { inFile = new BufferedReader(new FileReader("C:\\Java\\settings.ini")); lastMod = new Date(Long.parseLong(inFile.readLine())); } catch (FileNotFoundException e) { e.printStackTrace(); } catch (IOException e) { e.printStackTrace(); } //Long block of code using inFile inFile.readLine(); inFile.close(); 

Versus:

 public static void main(String[] args) { Date lastMod = null; BufferedReader inFile = null; try { inFile = new BufferedReader(new FileReader("C:\\Java\\settings.ini")); lastMod = new Date(Long.parseLong(inFile.readLine())); //Long block of code using inFile inFile.readLine(); } catch (FileNotFoundException e) { e.printStackTrace(); } catch (IOException e) { e.printStackTrace(); } finally { inFile.close(); } 

Answer 1

B is more readable when nothing happens after the inner try block before the outer try block. If you have logic to execute between them, you should use A

In the second example, the second version, which uses finally, is critical to ensure that close will be called no matter what (even if the function returns first). The first version, finally, is actually incorrect, since you can use all files and cannot open more files.

As an additional note, you may need to check for null when calling close. And if you use java 7, it is better to use "try with resources" .

Answer 2

For the first question: Solution A adds unnecessary complexity. Use B or, if you are using Java 7, try with resources:

  Date lastMod = null; try (BufferedReader inFile = new BufferedReader(new FileReader("C:\\Java\\settings.ini"))){ lastMod = new Date(Long.parseLong(inFile.readLine())); } catch (FileNotFoundException | IOException e) { e.printStackTrace(); } 

For the second question: in the first version, what if creating a BufferedReader an exception? You would use br followed by null and throw a NullPointerException. Also, if something else happens, you will not call inFile.close() , so you really need finally . For all these reasons, again, the second solution is better.

If you use try-with-resouces (Java 7), of course, you do not need a finally block to release BufferedReader.

Answer 3

Appropriate technique may also include not catching your exceptions, but resolving them instead of bubbles. Always use the finally block to clear any state that might otherwise use resources, but you will often be better off avoiding the exception in the parent routine rather than in the child routine in which the exception was thrown.

In general, if it would be useful to know in the calling routine whether the routine was successful or not, then this routine should not catch its exceptions, but should allow them to bubble up to its caller.