Em java, tudo que não é primitivo é... objeto, certo? As exceções são instâncias da classe Exception.
Na verdade, a árvore começa com a classe Trowable.. Então, temos a seguinte hierarquia decrescente:
Trowable <-- Exception <-- RuntimeException <-- (Exceções Não verificadas)
No casa acima, acredito que devem ser tratadas com try/catch em algum lugar, o que depende da regra de negócio, do método utilizado, enfim...
Mas no caso das checkeds(verificadas) há a seguinte regra:
"Todo método deve ou tratar todas as exceções verificadas, fornecendo uma cláusula catch, ou então listar cada exceção verificada que não tiver recebido tratamento como uma exceção lançada."( Certificação Sun para Programador Java 6 - Guia de Estudo, Kathy Sierra e Bert Bates).
Estive dando uma olhada na API do java, na classe File, por exemplo. Há o seguinte método:
public String getCanonicalPath() throws IOException {
if (isInvalid()) {
throw new IOException("Invalid file path");
}
return fs.canonicalize(fs.resolve(this));
}
Nas exceções verificadas, o compilador nos obriga a declará-las na interface pública do método. No método do exemplo acima, se o meu canonicalPath não for válido, o método getCanonicalPath lançara uma exceção. Acredito que quem estiver chamando o método saberá, em função de um contexto particular, como melhor tratá-la. Sendo assim, penso que no caso das verificadas, é melhor deixar a responsabilidade para quem chama o método. Até porque, há "risco" de ocorrer a exceção, ela não ocorrerá necessariamente. Além disso, penso que deixar a responsabilidade para quem chama, torna o código mais flexível.
Abs.