Os Sete Hábitos das Exceções Altamente Eficazes

Transcrição

1 c o l u n a Mundo OO Os Sete Hábitos das Exceções Altamente Eficazes Aprenda os bons hábitos na modelagem de erros de uma aplicação A modelagem no tratamento de erros de uma aplicação é uma atividade que muitas vezes é deixada de lado na criação de uma arquitetura. Isso pode trazer diversos problemas que vão desde bugs difíceis de serem encontrados até o vazamento de informações que podem comprometer a segurança. Este artigo traz uma série de boas práticas que ajudam a evitar os erros mais comuns de serem cometidos e auxilia na criação de um bom modelo de exceções. Eduardo Guerra (guerraem@gmail.com): é desenvolvedor de frameworks, participando de projetos open-source como SwingBean, Esfinge Framework, ClassMock e JColtrane. Atualmente cursa doutorado no ITA, onde também já concluiu graduação em Engenharia da Computação e mestrado. Possui as certificações SCJA, SCJP, SCWCD, SCBCD (1.3 e 5.0), SCJWSD, SCMAD e SCEA e experiência como arquiteto de software nas plataformas Java SE, Java EE e Java ME. Atua também como professor na graduação do ITA e nos cursos de pós-graduação ITA/Stefanini. Omecanismo de processamento de erros é um importante fator que deve ser levado em consideração no momento de se modelar uma arquitetura. Infelizmente, em muitas aplicações, por questões de prazo ou inexperiência dos desenvolvedores, essa parte é deixada de lado. Isso pode levar a resultados catastróficos! O código pode ficar confuso e alguns erros mascarados, tornando-os difíceis, para não dizer impossíveis, de serem rastreados. Em alguns casos, uma má modelagem pode ocasionar em vazamento de informações do sistema que podem comprometer a segurança. O objetivo deste artigo é apresentar sete hábitos que devem ser seguidos ao se lidar com exceções dentro de uma aplicação. Inicialmente será apresentada uma pequena revisão sobre o funcionamento das exceções na linguagem Java. Em seguida, serão apresentadas sete boas práticas a serem seguidas pelos desenvolvedores para que o modelo de exceções seja altamente eficaz! Durante a apresentação das práticas, serão mostrados os principais erros que são cometidos ao se lidar com exceções. Entendendo exceções Diversas coisas podem dar errado no momento de execução de uma aplicação, e assumir isso no momento da modelagem de um sistema não é ser pessimista, e sim realista. Os erros podem ser devido a questões que estão fora do nosso controle. Por exemplo, qualquer acesso que for feito através de uma rede deve estar preparado para situações em que a rede esteja fora do ar, assim como acessos a um banco de dados devem assumir que a conexão pode não ser criada com sucesso. Esses são fatores normalmente externos à aplicação que está sendo construída. Existem também erros que ocorrem devido às entradas dos usuários. Por exemplo, o cadastro de um usuário que já existe na base de dados provavelmente irá violar alguma chave única na tabela onde ela é armazenada. Tentativas de entrar em funcionalidades as quais o usuário não deve executar irão ser bloqueadas por um componente de controle de acesso. É importante lembrar que os usuários do sistema também estão fora do nosso controle e os erros também podem acontecer através de suas ações. A grande questão é como modelar dentro da aplicação uma forma simples e elegante, de forma a indicar para quem chamou um determinado método que um erro ocorreu na sua execução. Antes da existência 28

2 de exceções em linguagens de programação, muitas vezes a solução era o retorno de valores específicos que deviam ser interpretados pela aplicação. Diversas funções acabavam implementando algum tipo de retorno com significado para indicar a existência ou não de erro. Por exemplo, imagine uma função que lê um número de um arquivo e coloca em uma variável. Uma forma de indicar se ocorreu algum erro seria retornar -1 para quando ocorresse um erro e 0 caso contrário. Esse tipo de estratégia muitas vezes não atende às necessidades da aplicação. Vejam algumas desvantagens desse tipo de abordagem: do e desconhecido por quem está invonca aquele procedimento; claro; ável retornar um valor com significado de erro. Imagine, por exemplo, uma função que retorne um valor booleano; erro ocorreu, onde o erro ocorreu e circunstâncias nas quais ocorreu. Felizmente, a linguagem Java possui um mecanismo elegante para o tratamento de erros: as exceções. Com elas é possível enviar os erros ocorridos durante a execução de um método para quem os invocou, independentemente do tipo do retorno. Existe também a diretiva try{... catch(...){... finally{... que provê uma forma dessas exceções serem tratadas. Na próxima seção, será detalhado como funciona o modelo de exceções da linguagem Java. Funcionamento das exceções Como subclasse imediata de Throwable, temos a classe Error. As subclasses de Error representam erros que normalmente são lançados pela máquina virtual, pelo class loader ou outro tipo de código de suporte, ou seja, erros não previstos pelo programador. Normalmente não existem erros específicos da aplicação desse tipo e, por serem erros irrecuperáveis, raramente se deve também tentar tratar problemas desse tipo. Exemplos de subclasses de Error são OutOfMemoryError, que é lançada quando a máquina virtual falha na tentativa de uma alocação de memória, e StackOverflowError, quando ocorre um estouro na pilha de chamada de métodos da máquina virtual. Outra subclasse de Throwable é a classe Exception, que representa situações excepcionais que podem ocorrer durante a execução de um programa. Como subclasse de Exception, destaca-se uma classe especial chamada RuntimeException, cujas subclasses possuem um tratamento diferenciado de outras hierarquias que se derivam diretamente de Exception. As subclasses de RuntimeException normalmente representam erros da aplicação que não são recuperáveis e por esse motivo o desenvolvedor não é obrigado a tratá-los em um código onde existe a possibilidade deles serem lançados. Por esse motivo, elas são conhecidas como exceções não-checadas. Exemplos de RuntimeExceptions são: ArithmeticException, quando ocorre uma situação excepcional em algum cálculo aritmético, como divisão por zero; ArrayIndexOutOfBoundsException, quando tenta-se acessar um índice de um array que está fora dos seus limites; e o famoso NullPointerException, que indica a tentativa de se invocar um método ou acessar um atributo em uma referência nula. Exception Throwable Error A figura 1 apresenta um diagrama explicativo com a hierarquia das exceções na linguagem Java. A classe Throwable representa a raiz da hierarquia de exceções, sendo que todo tipo de objeto que pode ser jogado de um método deve de alguma forma ser um subtipo dessa classe. RuntimeException Erros não recuperáveis lançados pela aplicação. Erros recuperáveis lançados pela aplicação. Erros não recuperáveis lançados pela máquina virtual, class loader e código de suporte. 29

3 Outras subclasses de Exception que não tenham RuntimeException em sua hierarquia representam erros que são lançados e que obrigatoriamente devem ser tratados pela aplicação. Por esse motivo, elas são chamadas de exceções checadas. Uma das opções ao se executar um trecho de código onde pode ser lançada uma exceção em um método é passar o problema para quem o invocou. Isso pode ser feito propagando a exceção e declarando na assinatura do método que ele lança aquele tipo de exceção através da cláusula throws. Como consequência, quem chamar o método deverá também propagá-la ou tratar a exceção. Para uma exceção poder ser tratada, o trecho de código onde existe a possibilidade dela ser lançada deve ser envolvido em um bloco try. Este bloco deve ser sucedido de pelo menos um bloco catch ou finally. Os blocos catch são sempre seguidos de um parâmetro do tipo da exceção que ele trata. Por exemplo, um bloco do tipo catch(securityexception e) { será executado caso seja lançada uma exceção do tipo SecurityException ou qualquer subclasse da mesma. Diversos blocos catch podem ser criados para tratar diferentes tipos de exceção que podem ocorrer em um mesmo bloco try. Pode haver blocos catch para exceções da mesma hierarquia, porém as mais específicas devem vir primeiro e apenas o primeiro bloco, cuja exceção se encaixar, será executado. Caso a exceção ocorra, o fluxo de execução é imediatamente transferido para o bloco catch correspondente. Quaisquer comandos do bloco try que venham depois do erro ocorrer não serão executados. Dessa forma, se houver comandos que precisem ser executados em qualquer situação, eles devem ser colocados dentro do bloco finally. A regra de ouro é que o bloco finally será SEMPRE executado, tanto se o bloco try for executado normalmente até o final quanto se ele for terminado de forma abrupta, com a ocorrência de uma exceção ou com o retorno de um método. Isso mesmo! Quando o método possuir um comando return em um bloco try, o comando finally mesmo assim será executado. O finally com frequência é utilizado para tarefas de limpeza de recurso, como o fechamento de conexões. Uma exceção não precisa necessariamente ser lançada por métodos e classes de APIs e a aplicação também pode conter erros que façam sentido dentro do seu domínio. Apesar de tudo, uma exceção é uma classe como qualquer outra e pode possuir atributos para guardar informações e comportamentos implementados em métodos. O comando throw é utilizado para lançar uma instância de qualquer classe que herda de Throwable. A Listagem 1 apresenta o código da classe ServicoUsuario que exemplifica o uso de exceções. O método cadastra() é um método que cadastra um usuário em uma base de dados, mas que chama o método procuratrechocomum() para verificar a força da senha. Esse método verifica se existem três caracteres consecutivos do login que são utilizados na senha. O método cadastra() lança a exceção SenhaFracaException caso o método procuratrechocomum() retorne um valor diferente de nulo. A exceção SenhaFracaException estende diretamente a classe Exception e por esse motivo o método cadastra() precisa declarar que existe a possibilidade dessa exceção ser lançada. No método main(), onde esse método é invocado, a exceção é tratada através de um bloco try. O primeiro bloco catch trata a ocorrência de SenhaFracaException, informando ao usuário que a senha é fraca e sugerindo uma nova senha. É importante observar que esse trecho do código utiliza uma informação da classe da exceção, que é o trecho do login que foi encontrado na senha, para sugerir uma mudança na senha (bem trivial nesse caso, mas que poderia ser algo mais sofisticado). O outro bloco catch irá tratar quaisquer outras exceções que vierem a ocorrer, inclusive as que herdarem de RuntimeException. Uma observação interessante é que quando uma SenhaFracaException for lançada e o fluxo for redirecionado para o primeiro catch, o segundo não será executado, apesar dessa exceção também ser uma subclasse de Exception. O bloco finally, por outro lado, será sempre executado, tanto no caso de ocorrer exceções quanto no caso de nenhuma ocorrer. Listagem 1. Exemplo de uso do mecanismo de exceções. public class ServicoUsuario { public String procuratrechocomum(string login, String senha){ for(int i=0; i<login.length()-4; i++){ String sub = login.substring(i,i+3); if(senha.contains(sub)){ return sub; return null; public void cadastra(string login, String senha) throws SenhaFracaException{ String trecho = procuratrechocomum(login, senha); if(trecho!= null){ throw new SenhaFracaException(trecho); //cadastra usuário em base de dados public static void main(string[] args) { String login = args[0]; String senha = args[1]; ServicoUsuario serv = new ServicoUsuario(); try { serv.cadastra(login,senha); System.out.println( Cadastro com sucesso ); catch (SenhaFracaException e) { System.out.println( Tente uma senha mais forte. ); String sugestao = ); System.out.println( Sugestão de nova senha: +sugestao); catch(exception e){ //Trata outros erros finally{ System.out.println( Obrigado por usar o nosso cadastro! ); Quando qualquer classe de exceção é criada, a máquina virtual cria o seu stack trace e armazena dentro dela. Isso é uma informação extremamente valiosa na tentativa de detecção de um erro. O stack trace de uma exceção, que normal- 30

4 mente é impresso no console ou armazenado em um arquivo de log, contém a pilha de chamada de métodos do ponto de ocorrência do erro. Nessa pilha, estão todos os métodos que foram chamados, com as devidas informações de classe e linha de código (quando essa informação está disponível no bytecode), desde o método main() ou o início de uma Thread até o ponto onde o erro ocorreu. O objetivo desta seção foi dar uma visão geral sobre o uso de exceções. Espera-se que esse pequeno resumo sirva para os leitores poderem recordar os conceitos sobre o assunto e acompanharem o restante do artigo. As próximas seções irão apresentar sete importantes hábitos para lidar com exceções de uma forma eficiente em uma aplicação. Como ficou claro desde o início do artigo, o uso de exceções deve ser feito para tratamento de erros. Infelizmente alguns desenvolvedores subvertem esse uso e utilizam exceções como uma forma de passar informações entre métodos ou para o controle do fluxo de execução. A Listagem 2, por exemplo, apresenta um uso indevido do mecanismo de exceções. O array que é recebido como parâmetro pelo método soma, é percorrido dentro de um loop infinito. No momento em que houver uma tentativa de acesso a um índice inválido do mesmo, a exceção ArrayIndexOutOfBoundsException será lançada. Isso irá fazer com que o fluxo de execução saia do loop while(true){ e seja redirecionado para o bloco catch correspondente. Listagem 2. Uso indevido do mecanismo de exceções. public int soma(int[] array){ int i = 0; int soma = 0; try { while(true){ soma += array[i]; i++; catch (ArrayIndexOutOfBoundsException e) { return soma; O uso de exceções para redirecionar a saída de loops ou fazer desvios no fluxo de execução é uma má prática. A primeira desvantagem é que o código fica menos legível e de difícil entendimento. Além disso, esse tipo de construção pode evitar que a máquina virtual realize otimizações no bytecode em tempo de execução resultando em um pior desempenho. Dessa forma, as exceções devem ser utilizadas para aquilo que foram criadas: tratamento de erros! uma granularidade adequada Como foi visto na parte introdutória sobre exceções, nos métodos onde é possível que uma exceção seja lançada, com exceção das RuntimeExceptions, é necessário declarar isso na assinatura dos métodos. Da mesma forma que os parâmetros e o retorno de um método devem ser modelados, as exceções que ele lança também são fatores a serem pensados e modelados. Exemplos de problemas que podem acontecer estão representados na Listagem 3. O método1() declara um número muito grande de erros, mostrando que o que pode dar errado naquele método não foi algo planejado. Isso dificulta o cliente do método no tratamento dos erros, obrigando-o a criar diversos blocos catch. Em um sistema bem modelado, os métodos são razoavelmente coesos, o que faz com que os tipos de erro que possam ocorrer façam sentido dentro de um determinado domínio. Imagine por exemplo que em um método de autenticação as seguintes exceções possam ocorrer: LoginInvalidoException, para o caso do login não existir; SenhaInvalidaException, para o caso da senha daquele login estar errada; e TentativasEsgotadasException, no caso de haver três tentativas falhas na última meia hora para aquele login. Apesar de serem erros diferentes e que podem carregar informações diferentes, todos se referem a erros de autenticação. Sem esquecer que exceções são classes como quaisquer outras, é possível criar uma superclasse para todos esses erros chamada AutenticacaoException. O método poderia declarar que lança apenas a AutenticacaoException e, caso o cliente queira fazer um tratamento diferenciado para uma das subclasses, basta que um bloco catch seja criado antes do tratamento da superclasse. Listagem 3. Más práticas na declaração de exceções. public class Exemplo { //Um pesadelo para ser tratado no cliente... public void metodo1() throws MinhaException, OutraException, AlgumaOutraException, MaisOutraException {... //Tudo que existe de errado pode acontecer aqui! public void metodo2() throws Exception{... Voltando ao exemplo da Listagem 3, o método2() apresenta o outro extremo quando o método declara que lança a classe Exception. Isso é uma forma de dizer ao cliente daquele método que todo tipo de erro pode acontecer, o que na grande maioria das vezes não é verdade. Esse tipo de prática normalmente faz com que o tratamento dos erros que realmente podem acontecer não seja adequado. É importante que uma hierarquia das exceções que podem ocorrer dentro de uma aplicação seja bem modelada, de forma a ser representativa em termos da diversidade de erros e possuir abstrações que permitam uma representação de categorias de erros. Dessa forma, as exceções de método podem ser escolhidas de acordo com sua posição na arquitetura e de uma forma que representem os erros que podem ocorrer em uma granularidade adequada. 31

5 Essa prática é uma dica simples, mas que pode evitar terríveis dores de cabeça com erros difíceis de serem encontrados. Como foi dito nas primeiras seções deste artigo, quando uma classe descendente de Throwable é criada, dentro dela é armazenado o stack trace, que possui todos os métodos da pilha de execução desde o método main() ou o início da thread até onde aquele método foi invocado. O problema acontece quando uma exceção é criada e lançada pela aplicação por causa de outra. Imagine, por exemplo, que uma classe DAO que acessa o banco de dados utilizando JDBC recebe uma SQLException. Essa classe então cria um erro com maior nível de abstração e lança para o método que a invocou. Em muitos casos, essa nova exceção não leva as informações necessárias para que ao imprimir seu stack trace em um arquivo de log ou no console, seja possível detectar exatamente qual foi o erro que motivou a criação daquela exceção. A figura 2 ilustra a propagação correta e incorreta do stack trace da exceção que foi a causa real do erro. A classe Exception possui um construtor que recebe como parâmetro outra exceção. Quando esse parâmetro é utilizado, a Figura 2. Propagando o stack trace em exceções. impressão do stack trace é seguida por caused by e a mensagem e o stack trace da exceção causadora, e assim por diante. Quando o parâmetro não é utilizado, o stack trace impresso é somente o da exceção criada, tornando difícil a identificação de qual é o erro que realmente aconteceu. Esse hábito também pode ser chamado de Não reinvente a roda. A API padrão da linguagem Java provê diversas exceções de uso geral que podem e devem ser utilizadas pela aplicação. A vantagem de fazer isso é que a grande parte dos desenvolvedores já estão acostumados e sabem qual o significado que elas possuem. Abaixo seguem alguns exemplos de exceções da API padrão e exemplos de situações em que poderiam ser utilizadas: essa exceção pode ser utilizada em métodos que precisam validar parâmetros quando um valor inválido for recebido. Por exemplo, um método que espera receber como um valor inteiro um número de 0 a 100 representando um percentual, lançaria essa exceção caso recebesse um valor fora desses limites; essa exceção pode ser utilizada em classes onde a chamada de alguns métodos é inválida dependendo de seu estado interno. Uma classe que representa uma aeronave em uma simulação lançaria esse erro caso o método pousar() fosse chamado antes do método decolar(); este erro representa uma situação na qual foi recebido um índice que está fora do esperado. Normalmente pode ser utilizado quando o acesso a uma lista ou a um array é encapsulado por um objeto; esse erro é utilizado quando uma classe realiza uma tarefa que exige que seu estado se mantenha estático e concorrentemente tenta-se fazer uma modificação no mesmo. Como exemplo, imagine um Singleton que faça cache de uma lista, essa exceção poderia ser lançada quando a lista de objetos fosse percorrida e outra thread tentasse modificá-la de forma concorrente; muito utilizada quando uma determinada operação declarada em uma interface ou superclasse não é implementada pelas suas subclasses. As exceções citadas servem apenas para ilustrar como as classes existentes na API padrão podem ser utilizadas dentro de outros contextos. A grande lição que se pode tirar desse hábito é que antes de criar diversas classes de exceções, deve-se verificar se já não existe alguma que se encaixe. 32

6 Muitos desenvolvedores assumem que as únicas informações que devem estar disponíveis em uma exceção são o stack trace e a mensagem de erro, com o único objetivo de serem impressas no console. Como já foi dito algumas vezes neste artigo, as exceções são classes como quaisquer outras e podem possuir atributos e métodos. Dessa forma, é importante que essas classes de erro possuam informações a respeito das circunstâncias que o erro aconteceu. Na Listagem 1, apresentada no início do artigo, a exceção SenhaFracaException possui um atributo para armazenar a substring que foi encontrada em comum entre o login e a senha. Essa informação, no tratamento do erro, é levada em consideração para identificar qual trecho da senha precisaria ser substituído. Esse tipo de informação auxilia o cliente a fazer um tratamento adequado daquele tipo de erro. Vamos imaginar a existência de uma exceção chamada AutenticacaoException que representa uma autenticação falha. Informações óbvias sobre esse tipo de erro seriam qual o login e a senha enviados que não conseguiram se autenticar. Muitas vezes os desenvolvedores não acrescentam essa informação na exceção, pois assumem que quem irá tratar o erro está ciente do contexto de chamada do método que lançou a exceção. Isso nem sempre é verdade! Neste caso, o erro poderia ser enviado, por exemplo, para um componente que faz um controle da quantidade de falhas de autenticação por login nos últimos 30 minutos. Outras informações em relação aos erros em si também são bem valiosas! Uma exceção devido a uma falha de conexão que trouxesse a informação de quantas falhas consecutivas já ocorreu, pode ser extremamente útil para o cliente decidir se deve ser feita mais uma tentativa. Trazer esse tipo de informação muitas vezes torna o código do cliente mais simples, encapsulando o controle dela dentro da classe chamada. Não devemos esquecer das próprias mensagens de erro, que devem ser o mais claras e explicativas possível. Uma alternativa é sobrescrever o método getmessage() na exceção para retornar uma String criada com base em seus atributos. Uma mensagem bem descritiva poupa muitas dores de cabeça ao tentar identificar o que pode ter causado uma determinada exceção. Ignorar erros é um dos deslizes mais comum em relação a exceções. Esse tipo de coisa ocorre muito em sistemas grandes que já estão funcionando em produção. Começa como aquela solução temporária para fazer o código funcionar rapidamente, porém, como a maioria das soluções temporárias acaba se tornando definitiva, isso fica no código. Uma das consequências é que diversos erros que irão acontecer na aplicação irão passar despercebidos, muitas vezes mascarando motivos pelos quais certas funcionalidades não funcionam corretamente. A Listagem 4 apresenta algumas das formas de ignorar os erros. O exemplo mais clássico é deixar o bloco catch vazio. Dessa forma, o erro que ocorre é completamente ignorado e o programa continua como se nada tivesse acontecido. Isso faz com que muitas vezes a execução siga em frente assumindo que uma tarefa incompleta foi executada. Isso ocasionaria em exceções para acesso a bancos de dados algo como uma tela de inserção em que as informações são enviadas, o sistema diz ter as inserido com sucesso, porém, ao tentar recuperá-las, elas não estão na base de dados. O que aconteceu? Outro exemplo dessa má prática em métodos que possuem retorno é retornar null ao pegar uma exceção. Além de todos os problemas decorrentes de ignorar uma exceção, este caso ainda pode causar um NullPointerException em quem está invocando aquela função. Por mais que o método que está chamando esteja preparado para receber null em caso de erro, isso seria voltar àquela mesma situação antiga em que os métodos precisavam retornar valores especiais em caso de erro. Com a ocorrência de um erro dentro de uma aplicação, diversas medidas devem ser tomadas, como realizar o rollback em transações, registrar o erro para auditoria, tomar medidas para que um processamento posterior não seja executado e até mesmo enviar mensagens ao usuário avisando-o do problema ocorrido. Ignorar ou tentar mascarar esses erros dificulta a manutenção da aplicação e pode ter consequências ainda maiores com a execução do resto do programa. O quadro Tratamento de Erros no SwingBean traz uma experiência do autor em relação a esse tipo de problema. Listagem 4. Formas de ignorar erros. //Não faz nada! catch (Exception e) { //Retornar null catch (Exception e) { return null; //Loga o erro e continua catch (Exception e) { LOG.error( Blah, e); Alguns desenvolvedores acreditam que apenas logar o erro já é o suficiente para o tratamento de uma exceção. Isso é um grande erro e também uma forma de ignorar que eles aconteceram. A única diferença é que eles ficariam registrados, mas a execução do programa continuaria normalmente podendo causar os mesmos problemas descritos acima. 33

7 Tratamento de erros no SwingBean Quando comecei a desenvolver o SwingBean, a ideia era que os formulários fossem gerados mesmo se houvesse erros de configuração nos arquivos XML. Foi criado todo um mecanismo para contornar os erros e criar o formulário a qualquer custo. Havia pensado em fazer algo error friendly que funcionasse mesmo com erros. Quando o SwingBean começou a ser utilizado, eu logo percebi que essa decisão não havia sido muito boa. Alguns formulários começaram a não recuperar e popular certos campos sem que o desenvolvedor soubesse o motivo. Os erros eram mascarados pelo framework, que fazia o que podia para gerar os componentes gráficos, porém a aplicação não funcionava direito. Na versão seguinte, todos os erros de configuração eram lançados como exceções com mensagens bem explicativas e que ajudavam o desenvolvedor a encontrar facilmente os erros. Essa experiência me ensinou uma lição valiosa: nunca mascarar erros dentro de qualquer componente, deixando para quem o invoca essa decisão. O encapsulamento é um importante conceito da orientação a objetos, no qual o cliente de uma classe deve se preocupar apenas com a interface da mesma e não com o seu comportamento interno. Em uma arquitetura que utilize o conceito de camadas, as camadas mais baixas se preocupam com questões como o acesso a recursos e as camadas mais altas encapsulam a chamada às camadas mais baixas para formar as regras de negócio. JDBC DAO Serviço SQLException "Existe a chave da tabela X na tabela Y" DAOException "Não foi possível inserir no BD" ApplicationException "Não foi possível submeter sua ordem" Figura 3. Exemplo do nível de abstração de exceções. Da mesma forma que quem acessa as camadas mais altas da aplicação não deve ser preocupar com as funcionalidades das camadas mais baixas, também não deve haver preocupação com os erros que ocorrem em camadas mais baixas. Por exemplo, uma classe controller de uma aplicação web não deve se preocupar com um erro devido à ocorrência de uma chave duplicada no banco de dados, ou seja, não deve receber uma SQLException. Da mesma forma que as funcionalidades são encapsuladas, os erros também devem ser. Isso não quer dizer que um erro que ocorre devido a uma falha no acesso a base de dados não deva causar um erro na camada web. A questão é que o erro deve chegar com o nível de abstração correto para aquela camada. A figura 3 ilustra o encapsulamento de um erro ao passar por diversas camadas. Quando a arquitetura for projetada, devem ser definidos os erros que podem ser lançados por cada camada. Um erro de mais baixo nível deve ser encapsulado por uma exceção de mais alto nível para poder ser propagado. Não se deve esquecer da propagação também do stack trace conforme mencionado no Hábito 3 deste artigo. Deixar com que exceções de baixo nível se propaguem para a interface gráfica pode gerar um tremendo problema de segurança ao revelar informações de infraestrutura a possíveis atacantes. Uma mensagem de erro do banco de dados pode revelar qual banco é utilizado e até mesmo sua versão. Este tipo de erro sob o nome Error Message Information Errors, onde são listados os 25 erros de programação mais perigosos para a segurança de uma aplicação. Considerações finais Este artigo fez uma pequena revisão sobre o mecanismo de exceções e apresentou diversos bons hábitos que os desenvolvedores devem possuir ao modelar e implementar um mecanismo de tratamento de erros em uma aplicação. Junto com os bons hábitos, foram apresentadas as más práticas que são comuns de serem vistas em aplicações em produção. É importante ressaltar a relevância de um mecanismo de erros em uma arquitetura. Muitos desenvolvedores se preocupam com o caminho feliz, em que todo processo da aplicação ocorre da forma prevista, e deixando de lado o tratamento de situações excepcionais. Lembre-se que ignorar essas práticas pode ter consequências muito ruins como erros misteriosos difíceis de serem encontrados ou vazamento de informações que podem comprometer a segurança da aplicação. Você vai dar chance? Agradecimento Este artigo foi baseado numa aula para um curso de Tópicos Avançados em Orientação a Objetos que preparei em conjunto com meu amigo Alessandro Oliveira. Gostaria de deixar um agradecimento registrado a ele, pois o conteúdo deste artigo de certa forma teve a sua contribuição. Referências jun/09/java-exception-antipatterns/ top25errors/