Tratamento de exceções em Java
TRATANDO AS EXCEÇÕES
Veja agora um exemplo de aplicação utilizando esses conceitos de exceções e como devemos tratá-los.
Na classe anterior, utilizamos o conceito de exceções para tratar alguns problemas que poderiam ocorrer no nosso sistema. Por exemplo, imagine que alguém insira um valor zero na variável numérica num2; quando for efetuada a divisão, estará ocorrendo uma divisão por zero, o que não é possível, matematicamente; com isso, podemos tentar capturar um erro de ArithmeticException, como foi feito no primeiro
Outra exceção tratada foi a ArrayIndexOutOfBoundsException, que ocorre quando inserimos mais argumentos do que uma operação ou espaço alocado suporta. No nosso caso, suponha que alguém queira realizar uma de nossas operações, que foi programada para ocorrer sempre duas a duas, com apenas um argumento. Isso não iria funcionar; por isso, no exemplo resolvemos tratar essa exceção.
No último bloco catch, tratamos um erro que poderia ocorrer caso o usuário inserisse algum outro argumento diferente de números; isso lançaria a exceção NumberFormatException.
Até aí tudo bem, mas se você olhar com mais cuidado a nossa fi gura que mostra a família de exceções, perceberá que ArithmeticEx-
ception, ArrayIndexOutOfBoundsException e NumberFormatException
são fi lhas de RunTimeException, ou seja, são Unchecked Exception. Sendo assim, não precisam ser tratadas.
Pode surgir aí uma dúvida: por que existem exceções que devem ser tratadas e outras que não são obrigatórias?
Na verdade, tem a ver com o sentido semântico do erro e sua correção na regra implementada. Veja que faz muito mais sentido tratar uma exceção aritmética (ArithmeticException), de limitação de espaço ou de argumentos (ArrayIndexOutOfBoundsException) ou de formatação de tipo de dado (NumberFormatException) no próprio código a partir de blocos if-else do que deixar para a estrutura da JVM tratar esse erro. Afi nal, são erros de dados do negócio, todos eles estão contidos nas
RunTimeException. Esses tipos de possíveis erros são muito mais bem
tratados por meio de validações do que de exceções (que interrompem a JVM!), pois você quer que o usuário acerte.
Por outro lado, faz mais sentido deixar por conta da JVM os erros que não são RunTimeException; você faz apenas a interceptação desses erros, pois são associados à infraestrutura do sistema; são as Checked
Exceptions. Seria, por exemplo, um erro na rede, um problema com a
conexão de banco de dados ou outro erro que não faz parte do erro do usuário.
Na classe anterior, poderíamos então implementar a mesma classe, mas sem a estrutura try/catch; o compilador não reclamaria e o programa
AULA
7
INFORMAÇÕES SOBRE FÓRUM
Entre no fórum e apresente suas dúvidas. Participe, troque informações. Quem sabe você não pode colaborar com seus colegas?
Também não perca o chat da semana. Veja o horário e dia na página do fórum.
Reveja os principais conceitos estudados nesta aula.
• Nas linguagens procedurais, o que fazíamos para tratar um fl uxo fora do normal era tratar o retorno do método que executava esse fl uxo. Isso era feito por meio de uma marcação booleana em que o método retornava true se fosse executado, quando a aplicação chamadora imprimia uma mensagem de “método executado com sucesso”, ou algo parecido, ou retornava false se ocorresse algum problema, caso em que a aplicação chamadora imprimia uma mensagem de que algum problema havia ocorrido.
• A Orientação a Objeto desenvolveu formas mais elegantes de tratar os fl uxos anormais do sistema. Em Java, esse fl uxo anormal se chama
Exceptions (exceções), e a técnica utilizada para trabalhar erros de forma
correta é o chamado Tratamento de Exceções. R E S U M O
• No Tratamento de Exceções, caso a JVM não consiga encontrar o devido tratamento para aquela exceção que foi lançada (ou seja, você esqueceu ou não percebeu que poderia ocorrer aquele erro naquela classe), ela interrompe o fl uxo de execução e mostra o erro na saída do sistema, o que não parece muito adequado, pois o usuário não vai entender nada; é melhor você mesmo interceptar e tratar esse erro.
• Para evitar que a JVM “morra” devido a uma exceção não tratada, devemos tentar (try) executar o trecho de código suscetível ao erro; caso não consigamos, devemos pegá-lo (catch), discriminando qual foi o erro. As palavras reservadas entre as quais o código é inserido num bloco para tentar executar o código são try (tentar) e, para pegar a exceção e discriminá-la, catch (pegar).
• As subclasses filhas de Exception são divididas em dois grupos:
RuntimeException e suas subclasses num grupo; e todas as demais
subclasses de Exception no outro grupo.
• Todas as exceções filhas de RuntimeException são chamadas de
Unchecked Exceptions; seu tratamento não é obrigatório, uma vez que
você deve resolver esse tipo de erro no código; são exceções do negócio implementado.
• Todas as exceções que não são fi lhas de RuntimeException (Unchecked
Exceptions) são as chamadas Checked Exceptions. Neste caso, temos duas
opções: tratar as exceções com um bloco try/catch ou lançá-las para serem tratadas à frente pela classe que as utilizou por meio de throws; isso é feito para erros do sistema, de infraestrutura, como um erro na rede, um problema com a conexão de banco de dados ou outro erro que não faz parte do erro do usuário.
AULA
7
Na próxima aula, você irá estudar como trabalhar com algumas das principais bibliotecas de Java incluídas no JSE; vamos utilizar algumas de suas classes para ajudar na nossa programação do dia a dia. Até lá...