Exceções¶

Exceções transferem controle quando um método não pode cumprir seu contrato normal. Elas devem descrever falhas, não substituir desvios comuns de controle.

Exceções verificadas e não verificadas¶

exceções verificadas devem ser capturadas ou declaradas e podem descrever condições recuperáveis que se espera que o chamador considere;
subclasses de RuntimeException comumente sinalizam erros de programação, argumentos inválidos, estado ilegal ou falhas cuja recuperação local não é prática;
Error geralmente representa condições graves do runtime que o código da aplicação não deve rotineiramente capturar.

Esta taxonomia não decide uma API automaticamente. Considere se chamadores podem recuperar significativamente, se a falha é parte da abstração e como a API se integra a outras APIs.

Preservar contexto¶

static String readUtf8(Path path) {
    try {
        return Files.readString(path, StandardCharsets.UTF_8);
    } catch (IOException cause) {
        throw new UncheckedIOException("failed to read " + path, cause);
    }
}

O encapsulamento preserva a causa. As mensagens devem acrescentar contexto útil sem incluir segredos ou conteúdos sensíveis.

Segurança de recursos¶

Use try-with-resources para valores AutoCloseable. Ele fecha os recursos na ordem inversa à declaração e preserva falhas de fechamento como exceções suprimidas quando outra exceção já está sendo propagada.

Práticas¶

capture a exceção mais específica que puder tratar;
não registre e relance a mesma exceção em todas as camadas;
restaure o estado de interrupção ou propague InterruptedException quando uma camada não puder concluir a política de cancelamento;
evitar retornar null apenas para esconder falha;
traduza exceções de baixo nível nos limites de abstração, preservando a causa.