As has already been said in the comments programming errors like NullPointerException
should never be caught, they should be fixed. Ideally it should only occur during your developmental testing. So the best thing to do is to break the application so that you can fix it.
Only capture exceptions so that you can do something useful and recover from that error. Programming errors or even environment errors (caused by the JVM directly or indirectly) have no treatment. Even a ArithmeticException
is a programming error, you should not let a calculation give an error.
There we get into a certain controversy. The culture of Java indicates that in most cases where an operation can give a problem it should generate an exception and it must be handled to recover. In other cultures it is more common to follow the path of trying to avoid the error before it happens or check the error in another way (Java itself chooses this at various points) other than the exception. In these cases where you can check the error otherwise or you can avoid it I always prefer this path, most Java programmers prefer to let the exception occur even though it is a slower option . There are situations that only the exception is appropriate.
In cases where you should catch the exception itself, do so only where you can resolve something. Even if this something is just showing a message to the user or logging the error somewhere. If you can not solve the problem or do something useful to catch the exception?
Almost always printing the stack trace or doing something equivalent means that the application has given up and will break or at least get back to the beginning. why catching exception in the whole code to do the same thing? Let the exception bubble to the call stack and only treat in a neutral place.
My applications usually have a lot less catch
s that most Java applications out there, in some cases the difference reaches thousands.
And if you have throw
within catch
it almost always is an error.
If you really need to handle more than one exception at that same location you have two strategies:
-
The action to be taken is the same as a catch
with the OR operator to accept any of them:
try {
...
} catch(ExceptionCadastro | SQLException ex) {
...
}
-
If you need each error to have a different action use more than one catch
:
try {
...
} catch(ExceptionCadastro) {
...
} catch(SQLException ex) {
...
}
And will not capture Exception
unless you know what you're doing.
You can read more about it on the site . I highly recommend, most programmers do not understand and abuse exceptions.