Good practice with Java exception handling

5

What is the best way to work with more than one exception in Java?

In the code below, I see the possibility of giving two errors NullPointer or SQLException . If I put a catch for each exception is the best way?

public Boolean cadastro(Contato contato) throws SQLException, ExceptionCadastro {
    try {
        PreparedStatement p = (PreparedStatement) conexao.prepareStatement("insert into contatos (nome, email, telefone, endereco) values (?,?,?,?)");
        p.setString(1, contato.getNome());
        p.setString(2, contato.getEmail());
        p.setString(3, contato.getTelefone());
        p.setString(4, contato.getEndereco());
        p.executeUpdate();
        p.close();
    } catch (NullPointerException e) {
        e.printStackTrace();
    } finally{
        conexao.close();
    }
    return true;
}
    
asked by anonymous 25.02.2017 / 00:13

1 answer

9

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.

    
25.02.2017 / 15:36