Qual o melhor modo de tratar exceções exceções de infraestrutura (HibernateException, FinderException, NonUniqueObjectException, SQLException, CreateException, EJBException, etc) e exceções de erro de programação (NullPointerException, ClassCastException, etc) na camada dos EJBs? Como vocês fazem em geral? Uma opção bem comum é encapsular uma exceção unchecked e lançar, e deixar que o cliente cuide disso…
E, por extensão, chega na camada web, aka, actions. Como vocês fazem o tratamento? Lançam a exceção e deixam que o conteiner logue e usa os recursos da api para redirecionar para uma página de erro? Ou vocês mesmos tem um código de log e redirecionamento para uma página de erro?
Não existe uma estratégia única para isso, Rubem. Cada projeto tem uma forma diferente de lidar com exceções. Tem gente que simplesmente as ignora (o que é um erro), outros simplesmente logam em algum lugar e dão seqüência aos processos, outros capturam a exceção, logam e re-lançam para camadas superiores, sendo que cada uma destas 3 estratégias (podem existir mais estratégias) podem ser implementadas sob N-maneiras. Acho que cabe mais uma discussão em nível de projeto (talvez aí com a sua equipe) sobre este assunto, mas realmente não existe um padrão para tratar exceções.
Não tinha visto esse post. Enfim, aqui eu adoto que todas exceptions de infra são unchecked e são apenas tratadas no layer externo da aplicação (exception handlers do struts, por exemplo). Exceptions que dizem respeito à lógica de negocio são checked e normalmente dá pra contar todas com 1 mão apenas todas do projeto.
Em vários casos temos catch p/ exceptions unchecked para decorar elas com maior informação de contexto para melhorar a rastreabilidade, mas só.
[quote=Daniel Quirino Oliveira]
Não existe uma estratégia única para isso, Rubem. Cada projeto tem uma forma diferente de lidar com exceções. Tem gente que simplesmente as ignora (o que é um erro), outros simplesmente logam em algum lugar e dão seqüência aos processos, outros capturam a exceção, logam e re-lançam para camadas superiores, sendo que cada uma destas 3 estratégias (podem existir mais estratégias) podem ser implementadas sob N-maneiras. Acho que cabe mais uma discussão em nível de projeto (talvez aí com a sua equipe) sobre este assunto, mas realmente não existe um padrão para tratar exceções.[/quote]
É Danieal, é uma decisão de arquitetura de cada projeto, mas dependendo de como for feito, pode agilizar ou complicar o bugtracking.
Geralmente sigo o que o louds falou, faz mais sentido. Exceto com MDBs, em MDBs eu capturo mesmo as de infra e logo. A única diferença é que fica a cargo do próprio container logar (e o Log4J esta com uma configuração customizada para cada produto.).
Eu estava querendo saber se existem outras opções melhores.
Tratamento de exceções é um concern que deve ser tratado em paralelo, basicamente existem dois tipos que eu considero para tratar exceções, uma oriunda de operações do ambiente e outras das regras de negócio que foram violadas, por exemplo: SystemException e ( ApplicationException ou BusinessException ), e de uma forma ou de outra elas precisam ser exibidas para um determinado tipo de usuário, que pode ser um administrador do sistema, ou um usuário comum, devem a depender do tipo ser armazenadas em log.
Em exceções do tipo EJBException, e suas derivadas trata-se em uma classe HandlerException e que uma forma bem adequada para resolver esse problema com modularidade e reusabilidade é usando AOP. Com AOP você deixa o desenvolvedor livre de fazer chamadas explícitas no tratador de exceções, pois como ele é um aspecto, então agirá sobre os joinpoints definidos nos pointcuts. É formidável a maneira sucinta que esse concern é concebido com AOP.