Exceções em Java: erros, rastreamentos de pilha e lançamento

O que é uma exceção

Uma exceção é a maneira que o Java tem de dizer "algo deu errado e não consigo continuar normalmente". Em vez de retornar um valor ruim ou corromper seus dados silenciosamente, o ambiente de execução cria um objeto de exceção descrevendo o problema e o lança. A execução normal para nesse ponto, e o Java começa a procurar código que saiba como lidar com a situação.

Se ninguém a tratar, a exceção chega ao topo do seu programa, a JVM imprime um rastreamento de pilha e o processo encerra com um status diferente de zero.

public class Main {
    public static void main(String[] args) {
        int[] numbers = {10, 20, 30};
        System.out.println("before");
        System.out.println(numbers[5]);   // o índice 5 não existe
        System.out.println("after");      // nunca executa
    }
}

Repare que "after" nunca é impresso. No instante em que numbers[5] é avaliado, uma ArrayIndexOutOfBoundsException é lançada e o restante de main é abandonado.

Lendo um rastreamento de pilha

Quando uma exceção fica sem tratamento, você recebe uma saída como esta. Parece intimidante, mas é apenas uma lista:

Exception in thread "main" java.lang.ArithmeticException: / by zero
	at Main.divide(Main.java:8)
	at Main.main(Main.java:4)

Leia de cima para baixo:

• A primeira linha é o tipo (ArithmeticException) e uma mensagem (/ by zero).
• Cada linha at ... é um quadro de pilha. O de cima é onde a exceção foi de fato lançada - divide na linha 8. Abaixo dele está o chamador, main na linha 4.

A primeira linha at é onde você olha primeiro. Os quadros abaixo dela respondem "como chegamos até aqui?".

public class Main {
    static int divide(int a, int b) {
        return a / b;            // lança quando b é 0
    }

    public static void main(String[] args) {
        System.out.println(divide(10, 2));
        System.out.println(divide(10, 0));   // pá!
    }
}

Execute isto e o rastreamento aponta direto para a linha a / b, depois mostra main como o chamador. Essa cadeia de chamadas é a ferramenta de depuração mais útil que o Java oferece de graça.

A hierarquia de exceções

Toda exceção é um objeto, e todas descendem de Throwable. Os dois ramos que importam:

• Error - problemas graves que a JVM levanta, como OutOfMemoryError ou StackOverflowError. Em geral você não os captura.
• Exception - problemas que seu programa pode razoavelmente prever e tratar. Dentro dela fica RuntimeException, a mãe dos erros do dia a dia, como NullPointerException.

Throwable
├── Error                 (don't catch: OutOfMemoryError, StackOverflowError)
└── Exception
    ├── IOException        (checked)
    ├── SQLException       (checked)
    └── RuntimeException   (unchecked)
        ├── NullPointerException
        ├── ArithmeticException
        └── ArrayIndexOutOfBoundsException

Como são classes reais, uma exceção pode carregar uma mensagem e você pode perguntar a ela sobre si mesma:

public class Main {
    public static void main(String[] args) {
        try {
            int x = 10 / 0;
        } catch (ArithmeticException e) {
            System.out.println("type: " + e.getClass().getSimpleName());
            System.out.println("message: " + e.getMessage());
        }
    }
}

getMessage() retorna o texto após os dois pontos no rastreamento de pilha; getClass().getSimpleName() dá o tipo da exceção pelo nome.

Verificadas versus não verificadas

Esta é a distinção que mais confunde os iniciantes.

• Exceções não verificadas estendem RuntimeException. Geralmente significam um erro no seu código - um null que você não esperava, um índice ruim, uma divisão por zero. O compilador não obriga você a tratá-las.
• Exceções verificadas estendem Exception, mas não RuntimeException (por exemplo, IOException). Representam condições fora do seu controle - um arquivo ausente, uma conexão de rede que caiu. O compilador obriga você a capturá-las ou declará-las.

Se um método pode lançar uma exceção verificada, ele precisa dizer isso com throws, e todo chamador precisa lidar com ela:

public class Main {
    // declara que pode falhar com uma exceção verificada
    static void risky() throws Exception {
        throw new Exception("something went wrong");
    }

    public static void main(String[] args) throws Exception {
        risky();   // main também precisa tratá-la ou redeclará-la
    }
}

Remova throws Exception de main e o código nem sequer compila - é o compilador impondo o contrato das verificadas. Exceções não verificadas nunca exigem isso.

Lançando as suas próprias

Você não só reage às exceções - você pode levantá-las. Use throw com um novo objeto de exceção para sinalizar que um argumento ou estado é inválido. Isso é muito melhor do que retornar um valor mágico como -1 e torcer para que o chamador o verifique.

public class Main {
    static int squareRootInput(int n) {
        if (n < 0) {
            throw new IllegalArgumentException("n must be non-negative, got " + n);
        }
        return n;
    }

    public static void main(String[] args) {
        System.out.println(squareRootInput(16));
        System.out.println(squareRootInput(-4));   // lança com uma mensagem clara
    }
}

Inclua sempre uma mensagem que explique o que deu errado e, idealmente, o valor problemático - o seu eu do futuro lendo o rastreamento de pilha vai agradecer. IllegalArgumentException e IllegalStateException são as duas que você mais usará ao validar entradas.

Armadilhas comuns

• Engolir exceções. Capturar uma exceção e não fazer nada (um bloco vazio) esconde bugs. No mínimo, registre-a; normalmente você deve tratá-la ou relançá-la.
• Capturar Exception de forma ampla demais. Capturar a Exception base (ou pior, Throwable) pode mascarar problemas que você não pretendia tratar. Capture o tipo específico que você espera.
• Ler o rastreamento de baixo para cima. O quadro mais relevante é a linha at de cima, não a de baixo. Comece por ela.
• Confundir Error com Exception. Não tente se recuperar de OutOfMemoryError ou StackOverflowError; corrija a causa raiz.

Próximo: try-catch

Agora você sabe o que são as exceções e como lê-las. A próxima página aborda como realmente tratá-las: envolver código arriscado em um bloco try, recuperar-se no catch e executar código de limpeza no finally para que seu programa continue rodando em vez de quebrar.