O QUE SÃO EXCEÇÕES?

Exceções em Java têm o mesmo sentido semântico da palavra em

português, ou seja, uma exceção acontece quando a regra não é respei- tada, seguida; a regra, nesse caso, é o fl uxo normal (fl uxo principal) do programa. Portanto, ocorre uma exceção sempre que algo der errado ou fugir do fl uxo esperado na nossa aplicação, por isso o nome exceção para tratamento de erro.

O tratamento de exceções, como também é chamada essa técnica em Java (termo originado de tratamento de erros), é bem diferente do que fazíamos quando nossa programação não era Orientada a Objeto. Antes, 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 exe- cutado, quando então a aplicação imprimia uma mensagem de “método executado com sucesso” ou algo parecido, e retornava false se ocorresse algum problema, caso em que a aplicação imprimia uma mensagem de que algum problema havia ocorrido.

Essa forma de tratamento de erro tem vários problemas, e entre eles o mais criticado é que se consegue tratar apenas duas possibilidades: ou o fl uxo funcionou ou não funcionou. Além disso, nesse caso nunca se poderá defi nir a causa exata, pois um determinado fl uxo pode dar errado por várias razões.

O que podemos fazer para resolver isso?

Alguns programadores podem fi car tentados a ter a “maravilho- sa ideia” de, no lugar de retornar um booleano, retornar um inteiro e tratá-lo num bloco if-else-if e para cada inteiro retornar uma mensagem diferente relativa ao erro.

Isso está correto? NÃO... isso está errado, isso é uma má prática de programação (anti-pattern) chamada Magic Numbers. Nela, o pro- gramador cria números mágicos para cada erro. Esse tipo de prática tem manutenção extremamente complicada, pode incorrer numa quantida- de grande de erros e não dá semântica alguma ao código, que precisa retratar e explicar por si só o que está ocorrendo no mundo real por

AULA

7

Vou dar um exemplo. Imagine que você está implementando um sistema bancário no qual temos uma classe Conta que possui um méto-

do sacar que recebe o valor do saque, executa as operações de saque

(conexão com banco, validação de usuário, verifi cação de saldo e limite etc.) e retorna true ou false conforme o caso:

Se quisermos fazer o tratamento dos possíveis fl uxos que possam ocorrer por ocasião do saque, só conseguiremos tratar dois casos: ou o saque funcionou ou não funcionou:

Então, acho que você já se convenceu de que esse tipo de trata- mento não é uma boa ideia.

A OO 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.

No tratamento de exceções, a ideia é que você saiba quais tipos de erro um determinado trecho de código pode lançar, e então ele tem a obrigação de identifi car esse erro caso ele ocorra, enviando uma men- sagem adequada e tratada para o usuário, nesse caso. Parece difícil, quer dizer que é preciso conhecer todas as exceções do Java? Isso não fi ca muito complicado, pois, uma vez que a exceção esteja contida no código, a própria JVM se responsabiliza por desviar a execução para esse tratamento adequado, caso ele ocorra.

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 perce- beu que poderia ocorrer aquele erro naquela classe), ela interrompe o fl uxo de execução e mostra o erro na saída do sistema. Isso não parece muito adequado, pois o usuário não vai entender nada. É melhor você mesmo interceptar e tratar esse erro. Na verdade, essa interrupção de execução da JVM é uma proteção para garantir que seu programa não vá executar uma operação errada, num fl uxo que não é o normal, como já dissemos.

Então, 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 e, caso não consigamos, devemos pegá-lo (catch), discriminando qual foi o erro.

A palavra reservada inserida num bloco para tentar executar o código é try (tentar). Para pegar a exceção e discriminá-la a palavra reservada utilizada é o catch (pegar).

Se uma determinada exceção foi pega e identifi cada (ou seja, era esperada), a execução continua, já que a JVM supõe que você tomou as providências cabíveis.

Na verdade, Exception é uma classe que tem muitas “fi lhas”, como pode ser observado na Figura 7.1.

Vamos dividir as subclasses fi lhas de Exception em dois grupos: de um lado, RuntimeException e suas subclasses; no outro, todas as demais subclasses de Exception.

Todas as exceções fi lhas de RuntimeException são chamadas

Unchecked Exceptions; seu tratamento não é obrigatório, uma vez que

você deve resolver esse tipo de erro no código. Exemplos de exceções de Runtime: • ArithmeticException;

• NumberFormatException; • NullPointerException;

AULA

7

Todas as exceções que não são fi lhas de RuntimeException (Unchecked Exceptions) são chamadas Checked Exceptions. Nesse caso, temos duas opções: tratá-las num bloco try/catch ou lançá-las para serem tratadas à frente (numa outra classe que chamar essa que tem o erro), por meio de throws.

Veja a hierarquia de classes Exception:

java.lang java.util java.awt java.io java.net EmptyStackException NoSvchElementException ClassNotFoundException CloneNotSupportedException IllegalAccessException InstantiotionException InterruptedException NoSuchMethodException RuntimeException Object Throwable Exception AWTException IOException ArithmeticException ArrayStoreException ClassCastException IllegalArgumentException IllegalMonitorStateException IndexOutOfBoundsException NegativeArraySizeException NullPointerException SecurityException IllegalThreodSateException NumberFormatException ArrayIndexOutOfBoundsException StringIndexOutOfBoundsException IOFException FileNotFoundException InterruptedIOException UTFDataFormatException MalFormodURLException ProtocolException SocketException UnknownHostException UnknownServiceException

Veja a classe a seguir. Ela tem algum problema? Por quê? Como resolver?

No caso dessa classe, estamos utilizando a classe FileReader de

java.io para fazer a leitura de um arquivo que está num determinado

diretório; assim, você deve esperar, por exemplo, um erro tal que o arquivo não possa ser encontrado, o que é um tipo de IOException, do tipo FileNotFoundException, que não é fi lha de RunTimeException. É, assim, uma Checked Exception, e você é obrigado a tratá-la, caso contrário a classe não irá nem compilar, lançando qual exceção levou ao erro: unreported exception java.io.FileNotFoundException; must be

caught or declared to be thrown (erro apresentado pelo compilador).

Veja como é fácil perceber qual exceção deixou de ser tratada: o compilador mostra na sua janela de erro (com o tempo e a experiência, você aprenderá sobre elas).

Outro detalhe que merece atenção: já que uma classe pode fazer várias coisas, podemos ter mais de uma exceção e de repente todas checked.

Assim, podemos encadear tratamentos de exceção, mas cada um em um único bloco catch, já que as medidas podem ser diferentes para cada erro e os erros ocorrerão um de cada vez.

AULA

7

Vários erros também podem ser passados para a frente (nos dois casos deve ser dado import das classes referentes aos erros), mas sepa- rados por vírgula.