Então vamos as regras que separei baseado no que li por aí e na minha experiência desenvolvendo sistemas:
- Nunca trate (lance ou capture) a super classe Exception. Alguém pode pensar: "Mas porque eu preciso me preocupar com quais exceções devo tratar, se com Exception trato todas?". Eu vejo dois motivos: O primeiro é a clareza. Tratar exceções pela classe Exception é XGH (eXtreme Go Horse), pois não é possível verificar apenas olhando o código, que tipos de exceções são lançadas pois Exception pode ser qualquer problema. O segundo motivo, na minha visão, está relacionado à segunda regra, que diz respeito a diferença conceitual entre algumas exceptions;
- Nunca lance uma exceção técnica para a camada de negócio. Trate a exceção técnica na camada onde ela pode ocorrer, como por exemplo uma SQLException em um DAO, e lance uma Custom Exception para o seu domínio, como um AcessoDadosException;
- Nunca, mas nunca mesmo, silencie uma exceção. Quem for manter a sua aplicação (podendo até ser você mesmo) agradece. Exceções silenciadas representam um desastre para o debug, e os motivos são óbvios.
A primeira fonte de dados é o Oracle e a segunda é utilizando a API do ALBPM. Quando estamos tratando diretamente com o Oracle, podemos receber ClassNotFoundException e SQLException. Quando estamos tratando com a API, as possibilidades são IOException, PortalException e RemoteException.
Dois testes que tenho em AdministrativoDeve são:
- recuperarGruposPorParticipante(); - Oracle
- adicionarParticipanteNoGrupo(); - via API
No repositório de Grupos, temos os seguintes métodos:
- public List
recuperarGruposAtivosDe(Participante participante) throws AcessoDadosException; - public Integer adicionarUsuariosEm(Grupo group, List
participantes) throws AcessoDadosException;
Espero que o post tenha sido claro e fique a vontade se você trabalha de uma forma diferente e que também é eficiente para a sua equipe.
Excelente post.
ResponderExcluirInteressante a idéia de criar uma Exception para o domínio.
Falta material que trate de boas práticas de tratamento de Exceções.
[]'s
Obrigado pelo elogio e pela participação Gabriel!
ResponderExcluirExcelente post. Tenho uma pergunta:
ResponderExcluir"Nunca lance uma exceção técnica para a camada de negócio. Trate a exceção técnica na camada onde ela pode ocorrer, como por exemplo uma SQLException em um DAO, e lance uma Custom Exception para o seu domínio, como um AcessoDadosException"
ok entendi, porém não é um trabalho extra ? sabendo que é subententido que SQLException é uma exception de acesso a dados ? Considere que vc não está utilizando a segunda fonte, como a API...
abraços
@Renan obrigado pelo elogio.
ResponderExcluirQuanto a sua pergunta, o acesso a dados também pela API foi dado como exemplo do porque não lançar a SQLException. Vamos dizer que hoje você não tenha uma segunda forma de acessar os dados. E se amanhã você tiver? Vai ter que mudar todas as outras camadas?
Realmente é um trabalho extra, mas creio que necessário. O seu domínio não tem que saber se você está acessando dados via SQL, XML, API, sinal de fumaça, sei lá. O domínio precisa apenas saber que houve um problema de acesso a dados.
Agora pensa no seu cliente. Ele, necessariamente, tem que saber o que é uma SQLException? Não fica mais claro para ele AcessoDadosException?
Abraços
Excelente explicação, muito obrigado. Sucesso
ResponderExcluir@Renan
ResponderExcluirEu que agradeço a sua participação.
Obrigado