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

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.