[quote=victorwss][quote=dambros][quote=mr.zanini]puxa… na facul o professor ensina a tratar sempre o erro…
pensei que precisasse…[/quote]
Sinceramente é exatamente o contrário. Pode perguntar para outras pessoas, o correto é tentar não ficar tratando exceções a não ser que elas sejam mesmo necessárias, pois o correto é você consertar o código para que ele não fique dando a exceção.
No começo eu tambem tentava usar exceção em tudo, ainda mais depois que descobri o eclipse e que ele fazia isso para mim com apenas alguns cliques. Hoje em dia tento tratá-las apenas quando seja imprescindível.
Muitas vezes o uso de exceção é comum quando você quer controlar algo do tipo:
Usuário realizada uma tarefa de forma incorreta, isso gera um erro. Para que o programa não feche, você trata a exceção isolando-a e dessa forma faz com que o programa continue sendo executado.
Mas posso estar enganado, como falei acima sou principiante em java.[/quote]
Você está enganado. Basicamente, existem três tipos de exceções em java: As que herdam de RuntimeException, as que herdam de Exception mas não de RuntimeException e as que herdam de Error.
RuntimeExceptions indicam erros de programação, tal como NullPointerException, ArrayIndexOutOfBoundsException, ClassCastException, NumberFormatException.
Errors indicam problemas graves (e geralmente imprevisíveis e intratáveis) para os quais geralmente não há conserto, tal como OutOfMemoryError, StackOverflowError, NoClassDefFoundError, NoSuchMethodError, ExceptionInInitializerError, AssertionError. Podem indicar erros de programação graves.
Já as Exceptions são os erros previstos, e essas o compilador vai exigir que você trate adequadamente. Essas tem origem em operações que podem falhar por coisas que não dependem do programa e nem de condições extremas, ou seja, podem acontecer mesmo se a lógica do programa estiver perfeita e este estiver íntegro.
Exemplos são SQLException, IOException, InvocationTargetException, SocketException, FileNotFoundException.
Por exemplo, uma operação de salvar algo em um arquivo é normal, mas mesmo com a lógica do programa perfeita, vai dar um IOException se o disco estiver cheio. O fato de IOException herdar de Exception faz com que o compilador exija que você trate essa exceção (porque indica uma situação que embora anormal, pode acontecer de vez em quando).
Daí é para isso que você usa o try-catch principalmente:
public void salvarDadosNoArquivo(AlgumObjeto dados) {
OutputStream os = blablabla;
try {
// Faz um monte de coisas com o arquivo.
} catch (IOException e) {
// Mostra uma mensagem indicando que o salvamento falhou e o motivo.
} finally {
try {
os.close();
} catch (IOException e) {
// Faz algo para tratar.
}
}
}
Então, no geral exceções que herdem de Exception, mas não de RuntimeException DEVEM ser tratadas. Para tratar a exceção ou você usa o try-catch, ou então lança ela para o método que a chamou. Existe um lugar certo para tratar exceções que depende de cada caso (cada caso é um caso). Tratar ela muito abaixo ou muito acima pode criar dificuldades para tomar-se ações corretivas e/ou obter-se informações suficientes sobre a falha.
Ah, e também há o encadeamento de exceções, que faz com que você veja que a VendaNaoAutorizadaException foi causada por uma ClienteEmDebitoException que foi causada por uma SQLException. Isso permite você ter a informação das falhas em todos os níveis do sistema afetados por elas, sem perder informação sobre o porque de sua ocorrência.[/quote]
Mas ao menos no sentido de não tratar exceções desnecessárias estava certo ne?
Senão so falei besteira pro cara.