Visão do Compilador

Ele se preocupa com todas as exceções que sejam subclasses de Exception, a menos que elas sejam de um tipo especial (RuntimeException). Toda classe de exceção que herde de RuntimeException tem passe livre, ou seja, para o compilador tanto faz se você declará-la na cláusula throws ou não, também não faz diferença se você a trata dentro de um bloco try/catch, para ele é como se as RuntimeException sequer existissem.

Espera aí! Mas por que tanto desprezo com as RuntimeException, o que elas têm de diferente das outras, afinal de contas, somos todas da mesma família! Então, vamos às explicações.

A maioria das RuntimeException são derivadas de problemas no seu código, ao invés de um problema que acontece em tempo de execução que você não poderia prever. Você não pode garantir que ao abrir um arquivo ele esteja lá, ou que o servidor está funcionando, mas você pode garantir que o seu código não faça acesso a um índice inexistente em um Array (é para isso que serve o atributo ‘length’).

Você desejará que as RuntimeException aconteçam durante o desenvolvimento. Você não desejaria ter o trabalho de tratar tal tipo de erro dentro de um bloco try/catch, por exemplo, e ter todo overhead de lidar com isso, para capturar alguma coisa na cláusula catch, que na realidade não deveria ter acontecido antes de tudo!

O bloco try/catch é para capturar condições excepcionais e não fluxo de código. Use a cláusula catch para tentar se recuperar de situações que você não pode garantir que irá acontecer com sucesso, ou, em último caso, exibir uma mensagem para o usuário e imprimir a pilha de erro para que alguém possa descobrir o que está errado!

Em exemplo clássico de uma RuntimeException é o famoso NullPointerException. Alguém já viu uma dessa antes? Aposto que sim! Esse tipo de exceção, como todos nos sabemos, acontece quando tentamos acessar uma referência de um objeto nulo!