What is good practice when casting an exception within if?

Question

What is the best practice in this case, use the Else even knowing that the if will or will not make an exception?

option 1 (with Else):

if (condicao){
  throw new RuntimeException("Mensagem");
}else{
  System.out.println("Não deu exception");
}

option 2 (without Else):

if (condicao){
  throw new RuntimeException("Mensagem");
}
System.out.println("Não deu exception");

Answer 1

Although this is prone to a strong sense of personal opinion, I believe that best practice is nay block the else.

The reasons are as follows::

Readability of the code

Adding nested blocks, although in this small example will not cause a big impact, will only make it harder to read the code and make it more complex.

In practice, this can lead to situations with multiple levels of validation, as I’ve seen sometimes in systems out there:

if (condicao1){
    throw new RuntimeException("Mensagem 1");
}else{
    System.out.println("Não deu exception 1");
    if (condicao1){
        throw new RuntimeException("Mensagem 2");
    }else{
        System.out.println("Ainda não deu exception 2");
        if (condicao1){
            throw new RuntimeException("Mensagem 3");
        }else{
            System.out.println("Ainda não deu exception 3");
        }
    }
}

For those who think I’m exaggerating, it wasn’t once or twice that I saw methods with validations of 5, 6 or more levels in financial systems methods with somewhat complex business rules.

It’s not necessary

A condition that includes an exception release, or other instruction that will interrupt the execution of the method does not need this type of construction. Unnecessary code is a waste of time.

It is better to separate the initial validations

The initial validations of a method do not need and probably should not influence the main logic of the method.

public int meuMetodo(String parametro) {

    if (parametro == null || parametro.isEmpty()) 
        throw new IllegalArgumentException("Parâmetro não informado!");

    //lógica aqui
    return 123;

}

Answer 2

From the performance point of view, there is no reason to choose between one and the other, the difference should be negligible. Although the representation of the two forms in the bytecode be different, the performance will be very similar, with a difference of a few cycles at most (in contrast, a miss cache L1 "wastes" 10-40 cycles, L2 more than 600).

From the point of view of readability, I believe it will depend on the semantics of your program. If the condition if refers to an exceptional case, I believe that the ideal is to omit the else:

if ( denominador == 0 )
    throw new RuntimeException("Não pode dividir por zero");
quociente = numerador / denominador;

On the other hand, if the condition if is part of a mutually exclusive set, so I think it would be interesting to include the else (or maybe even a else if):

if ( x < 10 )
    return foo(x);
else if ( 10 <= x && x <= 20 )
    throw new RuntimeException("x não pode estar dentro do intervalo");
else if ( 20 < x )
    return bar(x);
// else
//     throw new RuntimeException("Isso nunca deve acontecer");

Answer 3

Your if is a "Guard clause": a clause that, if true, prevents the execution of the rest of the method code (or a loop). Guard clauses always contain "jump" code, such as return, throw, break or continue. They serve as preconditions for execution of certain code blocks.

My personal opinion is that these clauses do not need to else, since the code will "jump" out anyway:

if (condicao) throw new RuntimeException("Oops");

.... resto do código

Imagine a method with many preconditions, using else would make the code more illegible.

Note that I also do the following for "Guard Clauses":

• I leave the code of if and "jump" on the same line
• do not use a block delimited with {}

See a answer to a similar question I did in the O.R..

In Martin Fowler’s classic book Refactoring, there is a refactoring to transform from nested conditionals to Guard clauses.

Answer 4

In my opinion, let alone context better. In general, a different context is started with { and finalized with }, and from the point of view of those who read the code, it amounts to things from the past that must be remembered so that the code can be understood.

For example:

public int metodo(int parametro) {
    if (parametero < 0) {
        throw new IllegalArgumentException();
    } else {
        // Estamos no contexto do else que está dentro do contexto do método.
        // Ou seja, você tem que ter estes dois contextos em mente.
        return 42 + parametro;
    }
}

Already here:

public int metodo(int parametro) {
    if (parametero < 0) {
        throw new IllegalArgumentException();
    }

    // Estamos no contexto do método, fora de qualquer if ou else.
    return 42 + parametro;
}

This becomes quite evident in codes like this:

public boolean validaCPF(String cpf) {
    if (cpf == null || cpf.length() != 11) {
        return false;
    } else {
        int a = 0, b = 0;
        for (int i = 0; i < 9; i++) {
            int c = cpf.charAt(i) - '0';
            if (c < 0 || c > 9) {
                return false;
            } else {
                a += c * (i + 1);
                b += c * (9 - i);
            }
        }
        a = (a % 11) % 10;
        b = (b % 11) % 10;
        if (cpf.charAt(9) - '0' == a && cpf.charAt(10) - '0' == b) {
            return true;
        } else {
            return false;
        }
    }
}

It’s much better this way:

public boolean validaCPF(String cpf) {
    if (cpf == null || cpf.length() != 11) return false;

    int a = 0, b = 0;
    for (int i = 0; i < 9; i++) {
        int c = cpf.charAt(i) - '0';
        if (c < 0 || c > 9) return false;
        a += c * (i + 1);
        b += c * (9 - i);
    }
    a = (a % 11) % 10;
    b = (b % 11) % 10;
    return cpf.charAt(9) - '0' == a && cpf.charAt(10) - '0' == b;
}

This demonstrates that if Else can be avoided, the code gets cleaner.