Opa,
Então, entendo que o legal é colocar sentido no código.
Realmente, isso aqui:
catch (Exception e)
resolve porque é a superclasse de exceções mais específicas.
Mas supondo que você queira executar alguma coisa caso um determinado tipo de exceção aconteça, mas o código pode lançar outras exceções que você apenas gravará num log ou algo do tipo.
É possível fazer algo assim:
try{
comando(s);
} catch (FileNotFoundException f) {
comando(s);
} catch (NullPointerException f) {
comando(s);
} catch (Exception e) {
log.error("texto da fora que quiser");
}
Lembrando que isso só funciona quando feito da mais específica para a mais genérica.
Percebe que dá pra colocar lógica dentro do tratamento de exceção?
Falar sobre o mais correto é complicado. O que não pode é deixar de tratar exceções e jogar stacks de erros na cara do usuário ..
Uma coisa legal a se fazer é aplicar conceitos como análise de valor limite e fronteiras nos testes dos programas, pois forçam erros. Isso tende a mostrar exceções não tratadas e deixar a aplicação mais resiliente.
