Refactor Exception Handling

Question

Ok i have sinned, i wrote too much code like this

try {
   // my code
} catch (Exception ex) {
   // doesn't matter
}

Now i'm going to cleanup/refactor this.

I'm using NB 6.7 and code completion works fine on first writing, adding all Exception types, etc. Once i have done the above code NB do not give more help.

Do you know a way to say NB look again for all Exception types and make the proposal for handling them and do code completion again ?

Answer 1

The problem is, that your catch-all handler "handles" all the exceptions, so there's not need for Netbeans to show any more hints.

If your exception handlers are already empty and you are planning to refactor them anyway, you can just temporarily remove them.

Tip: Auto-format your code, search for try and use bracket highlighting to find the matching catch blocks. Then remove all the handling code.

After that Netbeans will again propose various actions to handle the possible exceptions.

PS: Be careful, the default handling of Netbeans (i.e. just logging) is not always the best choice, either.

Answer 2

I just can provide the eclipse approach and hope that it's somewhat similiar with netbeans:

1. remove the try/catch statements -> eclipse will show compiler errors
2. use eclipse's quick tip to refactor the correct try/catch (or throw) statements

You may save your existing exception handling code to paste it in after the refactoring.

Edit

Tom had a very good comment regarding RuntimeException. So the procedure should better look like this:

1. copy the existing catch clause and paste to a notepad/text editor
2. remove the try/catch statements -> eclipse will show compiler errors
3. use eclipse's quick tip to refactor the correct try/catch (or throw) statements
4. paste the stored catch clause at the end of sequence of catch statements

This will preserve your exception handling of RuntimeExceptions (and subtypes!).

So from

try {
   Integer.parseInt("Force a RuntimeException");
   myInputStream.close();
} catch (Exception oops) {
   // catch both IOException and NumberFormatException
}

you go to

try {
   Integer.parseInt("Force a RuntimeException");
   myInputStream.close();
} catch (IOException oops) {
   // catch IOException
} catch (Exception oops) {
   // catch NumberFormatException
}

(although you could manually replace Exception by NumberFormatException in this case, but it's just an example)

Answer 3

PMD identifies all these places where you have empty catch blocks (PMD does much more actually). It has NetBeans integration, so give it a try.

After identifying all the places with empty catch blocks you will have to consider each one by itself:

• sometimes just log the message
• sometimes restructure nearby code. I.e. if you are catching a NullPointerException, add a null check instead.
• sometimes you will have to consider rethrowing (and declaring checked) exceptions.

Answer 4

When you ask for a proposal on how to handle the exceptions ...

There is no generally accepted way to handle them. Otherwise, you bet the java language would have implicitly that behavior.

• Exceptions are not a low-level constraint that one must deal with until the compiler is smart-enough.
• Exceptions are a high-level language construct, used to express the semantic "something exceptional happened, whose treatment you don't want to mix with the regular code ; you prefer it to be handle in specific codes".

---

Exceptions exist in two forms, by design:

• Checked Exceptions must be made explicit in each method that can throw them.
• Unchecked Exceptions (subclasses of RuntimeException or Error) are usually implicit.

At each level of code (method or block), the code has to choose what to do, in the event of any exception (except unchecked exceptions that can omit the treatment altogether). This is a choice of responsibility that varies, there is no decision valid for all cases :

• PROCESS : Catch it and fully process it (calling codes typically don't to know something happened). The current method need to have the responsibility. Logging the stack-trace for the developper might be useful.
• STEP : Catch it, do a step of the processing that is related to the local code, and rethrow it (or rethrow another exception with the original one as a cause).
• IGNORE : just let it to the responsibility of the calling code.

The java language lets you have specific syntaxes making easier to handle exceptions, like the catch of specific exceptions followed more general ones...

---

Typically, you consider Exceptions in your architecture, and make some design decisions. Some examples (mixed in unique ways):

• choose to have one layer process all exceptions thrown in lower layers (ex : transactional services) : logging for the developper, positionning some global information for the user ...
• let some exceptions go up a few method calls until you arrive in a code where it is meaningful to process it (for example, depending on your exceptions, you can retry a full operation, or notify the user ... )
• etc.