Exceptions Em Java UFF

1,611 views

Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Exceptions Em Java UFF

  1. 1. Exceptions em Java Leonardo F reitas - [email_address] Apresentação disponível em http://www.ic.uff.br/~lfreitas Número de slides: 44 Duração: 2h
  2. 2. Reflexão "A mente que se abre a uma nova idéia jamais voltará ao seu tamanho original." Albert Einstein - A vida é um eterno aprendizado - Ninguém é o dono da verdade - Seja crítico - Nunca desista
  3. 3. Exceptions em Java - Agenda <ul><li>A estrutura try catch finally </li></ul><ul><li>Hierarquia de exceções </li></ul><ul><li>Definindo melhor exceções </li></ul><ul><li>Introdução </li></ul><ul><li>Vantagens da manipulação de exceções </li></ul><ul><ul><ul><li>Manipulando uma hierarquia inteira de exceções </li></ul></ul></ul><ul><li>Correspondência de exceções </li></ul><ul><li>Declaração de exceções e a interface pública </li></ul><ul><li>Por que objetos do tipo error não são simplesmente do tipo exception </li></ul><ul><li>Relançando a mesma exceção </li></ul><ul><li>De onde vêm as exceções </li></ul><ul><ul><li>Exceções lançadas pela JVM </li></ul></ul><ul><ul><li>Exceções lançadas programaticamente </li></ul></ul><ul><li>Resumão de BOAS PRÁTICAS </li></ul>
  4. 4. Introdução <ul><li>Um velho axioma relacionado ao desenvolvimento de softwares diz que 80% do trabalho (esforço necessário para identificar e manipular erros) são usados em 20% do tempo </li></ul><ul><li>Na programação estruturada , desenvolver programas que lidam com erros é monótono e transforma o código-fonte do aplicativo em um emaranhado confuso. </li></ul><ul><li>Na programação orientada a objetos , aqui especificamente na Linguagem Java , existe um mecanismo sofisticado para manipulação de erros que produz códigos de manipulação eficientes e organizados: a manipulação de exceções. </li></ul>
  5. 5. Introdução <ul><li>Definição simples de exceção : condição excepcional que altera o fluxo normal do programa </li></ul><ul><li>Algumas causas : falhas de hardware, exaustão de recursos e erros diversos </li></ul><ul><li>Nomenclatura : quando um evento excepcional ocorre em Java, diz-se que uma exceção será lançada. O código que é responsável por fazer algo com a exceção é chamado de manipulador de exceções , que captura a exceção lançada. </li></ul>
  6. 6. Vantagens da manipulação de exceções <ul><li>Fácil detecção de erros sem a escrita de um código especial para testar valores retornados; </li></ul><ul><li>Permite manter um código de manipulação de exceções nitidamente separado do código que gerará a exceção </li></ul><ul><li>Permite que o mesmo código de manipulação de exceções lide com as diferentes exceções possíveis. </li></ul>
  7. 7. <ul><li>A palavra chave try indica um bloco de código no qual possam ocorrer exceções (região protegida); </li></ul>As estrutura try catch finally <ul><li>Uma ou mais cláusulas catch associarão uma exceção específica (ou classe de) a um bloco de código que a manipulará </li></ul><ul><li>finally é o bloco apropriado para a limpeza depois da execução do código no bloco try (por exemplo, para fechar um arquivo ou liberar um socket * )‏ </li></ul>* Especificamente em computação, um soquete pode ser usado em ligações de redes de computadores para um fim de um elo bidirecional de comunicação entre dois processos. A interface padronizada de soquetes surgiu originalmente no sistema operacional Unix BSD (Berkeley Software Distribution); portanto, eles são muitas vezes chamados de Berkeley Sockets . É também uma abstração computacional que mapeia diretamente a uma porta de transporte (TCP ou UDP) e mais um endereço de rede. Com esse conceito é possível identificar unicamente um aplicativo ou servidor na rede de comunicação IP.
  8. 8. <ul><li>Exemplo de try catch </li></ul>
  9. 9. <ul><li>Exemplo de try catch </li></ul>
  10. 10. <ul><li>Exemplo de try catch finally </li></ul>
  11. 11. <ul><li>Exemplo de try catch finally </li></ul>
  12. 12. <ul><li>Exemplo prático de try catch finally (sem tratamento)‏ </li></ul><ul><li>Output </li></ul>
  13. 13. <ul><li>Exemplo prático de try catch finally (revisado)‏ </li></ul><ul><li>Output </li></ul>
  14. 14. Definindo melhor exceções <ul><li>Em Java , tudo que não for um tipo primitivo deve ser um objeto (inclusive as exceções)‏ </li></ul><ul><li>Toda exceção é a instância de uma classe que possui a classe Exception em sua hierarquia de herança. Em outras palavras, as exceções são sempre alguma subclasse de java.lang.Exception </li></ul>
  15. 15. <ul><li>Exemplo de exceção: </li></ul><ul><li>Neste exemplo, e é a instância de uma classe chamada resumidamente de ArrayIndexOutOfBoundsException . Como ocorreria com qualquer outro objeto, seus métodos podem ser chamados. </li></ul>
  16. 16. Hierarquia de exceções <ul><li>Error : situações incomuns que não são causadas por erros no programa e indicam eventos que não ocorreriam normalmente durante sua execução (exemplo: a JVM ficar sem espaço na memória). Geralmente os aplicativos não conseguem se recuperar de um erro, portanto não precisamos manipulá-los. </li></ul><ul><li>Erros tecnicamente não são exceções, pois não derivam da classe exception </li></ul>
  17. 17. Hierarquia de exceções <ul><li>A classe throwable fornece aos seus descendentes alguns métodos úteis em manipuladores de exceções. </li></ul><ul><li>O método printStackTrace () , por exemplo, exibe o rastreamento de pilha do local onde a execução ocorreu, através do processo chamado de desenrolamento de pilha . </li></ul>
  18. 18. Manipulando uma hierarquia inteira de exceções <ul><li>Se a classe especificada na cláusula catch tiver subclasses, qualquer objeto de exceção com subclasses da classe especificada também será capturado </li></ul><ul><li>Exemplo: IndexOutOfBoundsException </li></ul><ul><ul><ul><ul><ul><li>ArrayIndexOutOfBoundsException </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>StringIndexOutOfBoundsException </li></ul></ul></ul></ul></ul>
  19. 19. Correspondência de exceções <ul><li>Propagação top-down na pilha de camadas. </li></ul><ul><li>Exemplo: </li></ul><ul><li>Não funciona, pois há possíveis exceções derivadas de IOException que não foram tratadas (por exemplo EOFException )‏ </li></ul>
  20. 20. <ul><li>Agora sim, IOException abrange todas as exceções que podem ocorrer na região protegida: </li></ul>
  21. 21. Correspondência de exceções <ul><li>Manipuladores de exceções mais específicos devem sempre ser inseridos acima dos de exceções gerais </li></ul><ul><li>Para exceções que sejam irmãs na hierarquia de classes, a ordem não importa </li></ul>
  22. 22. Correspondência de exceções <ul><li>Exemplo prático: </li></ul><ul><li>Compila ? </li></ul><ul><li>Compila ? </li></ul>
  23. 23. Correspondência de exceções <ul><li>Exemplo prático: </li></ul><ul><li>Compila ! </li></ul><ul><li>Não Compila ! </li></ul>
  24. 24. Declaração de exceções e a interface pública <ul><li>Assim como um método precisa especificar que tipo e quantos argumentos aceitará e o que será retornado, as exceções que um método pode lançar devem ser declaradas (a menos que sejam subclasses de RuntimeException )‏ </li></ul>RuntimeException hierarchy
  25. 25. Declaração de exceções e a interface pública Exceptions hierarchy
  26. 26. Declaração de exceções e a interface pública <ul><li>A palavra-chave throws é usada da forma descrita a seguir para listar as exceções que um método pode lançar: </li></ul>
  27. 27. Declaração de exceções e a interface pública <ul><ul><ul><li>O compilador não verifica declarações de classes derivadas de RuntimeException </li></ul></ul></ul><ul><ul><ul><li>Só por que o método declara que lança uma exceção não significa que sempre o fará . Ele apenas informa que pode fazê-lo </li></ul></ul></ul><ul><ul><ul><li>Se você declarar a exceção que seu método capturará de outro método e não fornecer um bloco try/catch para ele, então o método propagará a exceção de volta para o método que o chamou e ela será capturada ou continuará a ser transferida através do fluxo, para ser manipulada por um método mais abaixo na pilha </li></ul></ul></ul><ul><ul><ul><li>Qualquer método que puder lançar uma exceção, inclusive os métodos que estiverem apenas transferindo uma exceção para o próximo método da pilha, também devem declará-la ( a menos que ela seja uma subclasse de RuntimeException )‏ </li></ul></ul></ul><ul><li>Observações bem importantes : </li></ul>
  28. 28. Declaração de exceções e a interface pública <ul><li>Requisito “Tratar ou declarar” (ou “Capturar ou declarar”): </li></ul><ul><ul><li>“ 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” </li></ul></ul>
  29. 29. Declaração de exceções e a interface pública <ul><li>Exemplo: </li></ul><ul><li>Problema: O método doMore () lança uma exceção verificada, mas não a declara! </li></ul><ul><li>Se declararmos o método doStuff () ainda apresentará problemas, porque ele também precisa declarar a exceção IOException , a menos que a manipule por meio do fornecimento de um bloco try/catch , com uma cláusula catch que possa tratar a exceção IOException </li></ul>
  30. 30. Declaração de exceções e a interface pública <ul><li>Voltando às exceções RuntimeException : </li></ul><ul><li>Como vimos, um objeto do tipo RuntimeException pode ser lançado de qualquer método sem ser especificado como parte da interface pública do método (e sem a necessidade de um manipulador)‏ </li></ul><ul><li>Mesmo se um método declarar realmente uma exceção RuntimeException , o método que o chamar não será obrigado a manipulá-la ou declará-la (pois ela faz parte das unchecked exceptions )‏ </li></ul>
  31. 31. Declaração de exceções e a interface pública <ul><li>As exceções RuntimeException , Error e todos os seus subtipos são unchecked exceptions e as unchecked exceptions não precisam ser especificadas ou manipuladas. </li></ul>
  32. 32. Declaração de exceções e a interface pública <ul><li>Vejamos uma checked exception na prática: </li></ul><ul><li>Vamos examinar myMethod1 (). Já que a exceção EOFException é subclasse de IOException , que, por sua vez, é subclasse de Exception , ela será verificada e deve ser declarada como uma exceção que pode ser lançada por esse método. </li></ul><ul><li>Agora, de onde realmente virá a exceção? A interface pública do myMethod2 () declara que uma exceção desse tipo pode ser lançada. Se ele realmente lançará a exceção ou chamará um outro método para lançá-la , não tem importância. Apenas sabemos que temos de capturar a exceção ou declarar que a lançamos. </li></ul><ul><li>O método myMethod1 () portanto não captura a exceção, ele declara que a lançará. </li></ul>
  33. 33. Declaração de exceções e a interface pública <ul><li>Atenção: Um códigos com um método que lance uma checked exception sem capturá-la em algum local não compila!! </li></ul>
  34. 34. Declaração de exceções e a interface pública <ul><li>Agora uma unchecked exception: </li></ul><ul><li>NullPointerException é derivada de RuntimeException , logo é unchecked e não precisará ser declarada (como no caso). </li></ul>
  35. 35. Porque objetos do tipo error não são simplesmente do tipo exception <ul><li>Objetos do tipo error não são objetos exception , embora representem condições excepcionais </li></ul><ul><li>Apesar de possível , não é comum lançar/capturar objetos do tipo error (como é feito com objetos do tipo exception ), pois são exceções da máquina, não do código de programação </li></ul><ul><li>Exemplos: </li></ul><ul><ul><li>Ao receber um objeto OutOfMemoryError a JVM já lutara desesperadamente para tratá-lo, logo não há o que fazer. </li></ul></ul><ul><ul><li>Ao receber um objeto VirtualMachineError o programa já estaria danificado. </li></ul></ul>
  36. 36. Relançando a mesma exceção <ul><li>É possível lançar a mesma exceção de acabou de ser capturada em uma cláusula catch </li></ul><ul><li>Exemplo: </li></ul><ul><li>Nesse caso, todas as outras cláusulas catch associadas ao mesmo bloco try serão ignoradas, um bloco finally , se existir, será executado e a exceção será lançada novamente para o método chamador (o próximo método na pilha de camadas)‏ </li></ul><ul><li>Atenção: se você lançar uma checked exception a partir de uma cláusula catch , também terá que declarar essa exceção!!! (Ou seja, terá que manipular e declarar, não manipular ou declarar)‏ </li></ul>
  37. 37. Relançando a mesma exceção <ul><li>Este exemplo não é válido : </li></ul><ul><li>Como a exceção foi lançada a partir de uma cláusula catch , é preciso declarar o IOException !! </li></ul>
  38. 38. De onde vêm as exceções <ul><li>Exceções lançadas pela JVM : As exceções ou erros que são ou exclusivos ou mais logicamente lançados pela JVM </li></ul><ul><li>Exceções programáticas: As exceções lançadas explicitamente pelo aplicativo e/ou pelos programadores da API </li></ul>
  39. 39. Exceções lançadas pela JVM <ul><li>Exemplo: NullPointerException </li></ul><ul><li>Neste caso, o programa tenta acessar um objeto usando uma variável de referência com um valor atual null . O compilador não encontra problemas desse tipo antes do tempo de execução. </li></ul>
  40. 40. Exceções lançadas pela JVM <ul><li>Exemplo: StackOverflowException </li></ul><ul><li>Iniciando a pilha de camadas, main chamará o go () , que chamará go () , que chamará go () … não há SO que agüente!!! (Nem o Chuck Norris SO…)‏ </li></ul>
  41. 41. Exceções lançadas programaticamente <ul><li>Relembrando : algo criado por um aplicativo e/ou por um desenvolvedor de API </li></ul><ul><li>Há muito tempo, algum programador escreveu a classe java.lang.Integer (classe Wrapper) e criou métodos como parseInt () e valueOf () . Esse programador decidiu sabiamente que, se um desses métodos recebesse uma String que não pudesse ser convertida em um número, o método deveria lançar uma NumberFormatException . </li></ul><ul><li>O código parcialmente implementado poderia se parecer com o seguinte: </li></ul>
  42. 42. Exceções lançadas programaticamente <ul><li>O desenvolvedor poderia ter usado IllegalArgumentException (lançada quando um método recebe um argumento formatado de forma diferente da que o método espera) para o método parseInt ()‏ </li></ul><ul><li>Quando criamos nossas próprias exceções podemos considerá-las como exceções lançadas programaticamente </li></ul><ul><li>Porém, quando há uma hierarquia de exceções, deve-se usar a exceção mais precisa que puder (no caso NumberFormatException extende IllegalArgumentException )‏ </li></ul>
  43. 43. Resumão de BOAS PRÁTICAS <ul><li>try/catch/finally = Use quando a classe for responsável por tratar o dito erro. Se o erro pode ser tratado mais para frente de uma maneira mais comum ao projeto, não utilize. </li></ul><ul><li>throws = Use quando o erro não for de responsabilidade da classe. Ela simplesmente será executada e lançará qualquer erro para ser mais adequadamente tratado em uma classe própria para isso. </li></ul><ul><li>Exemplo : Acessar de várias maneiras um servidor (seja via sockets ou um post ao servlet). Se uma maneira falha, a exception é jogada para frente, a classe tenta da outra maneira e trabalha com o erro gerado. </li></ul>
  44. 44. R // Até a próxima!!!!!!! P & P E R G U N T A S R E S P O S T A S

×