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 ?
['https://Stackoverflow.com/questions/2070933', 'https://Stackoverflow.com', 'https://Stackoverflow.com/users/114226/']
> 
> 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.
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)