Tratamento de Execeções em camadas

GUJ Master Membro desde: 24/04/2009 12:58:16 Mensagens: 1541 Offline

Sim....vc não pode lançar a mesma exception que tratou dentro do salvar.
Na verdade, a forma flexível é vc criar uma exception padrão sua de serviço que reflita erros da própria camada e lançar, emitindo uma mensagem padrão de serviço.
A camada adjacente usuário deve deter conhecimentos das exceptions internas ocorridas.

Continua o problema de não captura - la na camada de cima .

GUJ Master Membro desde: 24/04/2009 12:58:16 Mensagens: 1541 Offline

Fico ok agora!!!!

Continua oq??

public void salvar(){
        
        try{
            
           pessoaManager.adicionar(pessoa);
           
           pessoa = new Pessoa();
           pessoas = new ArrayList<Pessoa>();
           
           listar();
        
           FacesContext faces = FacesContext.getCurrentInstance();
           faces.addMessage(null, new FacesMessage(FacesMessage.SEVERITY_INFO,"Aviso", "Pessoa Salva com Sucesso!"));
            
        }catch(RegistroDuplicado rd){ // ele não entra nesse catch
            
            FacesContext faces = FacesContext.getCurrentInstance();
            faces.addMessage(null, new FacesMessage(FacesMessage.SEVERITY_FATAL,"Aviso", rd.getMessage()));
                 
        }catch(Exception e){ // ele sempre apresenta esse catch , caso eu tirar ele , não apresenta nada 
            
           FacesContext faces = FacesContext.getCurrentInstance();
           faces.addMessage(null, new FacesMessage(FacesMessage.SEVERITY_ERROR,"Aviso", "Instabilidades ao Salvar Pessoa."));
        
        }
   }

GUJ Master Membro desde: 24/04/2009 12:58:16 Mensagens: 1541 Offline

Vc ta lançando a exception devidamente no método salvar()...o código q vc postou não esta!

Estou lançando aqui

e capturando no salvar

GUJ Master Membro desde: 24/04/2009 12:58:16 Mensagens: 1541 Offline

Sua exception deve ser checkada!! como vc fez?

Olá. Vou mostrar como geralmente realizo o tratamento de exceções.

Tomemos um exemplo. Vamos supor que tenho a seguinte classe Usuario:

Agora tenho um service que faz o cadastro de um novo usuário usando um DAO:

E tenho um managed bean que contém um método que usa o service:

Partindo do cenário acima, vamos supor que quero inserir a seguinte regra:

Os campos login e senha não podem ser vazios.

Vamos começar criando uma classe para representar erros de negócio, conforme sugerido pelo colega FernandoFranzini:

Reparem que a exceção herda de RuntimeException. Isso é para evitar que precisemos declarar throws Exception em cada método que trata essa exceção.
Agora vamos modificar a classe Usuario para validar nossa regra:

Nosso service deve ser modificado agora para realizar esse tratamento, e propagar essa exceção para o managed bean. Se quisermos, podemos usar a idéia do colega FernandoFranzini e criar também uma exceção para representar erros nos services. Afinal, aqui podem acontecer erros de vários tipos além de erros de negócio.

Observem que na exceção anterior estamos passando pro construtor da superclasse a causa do erro. Isso é muito importante! Devemos sempre criar nossas exceções passando também a exceção que representa a causa.
Segue abaixo o service modificado:

Então, quando a exceção chegar no managed bean, fazemos o tratamento necessário:

GUJ Master Membro desde: 15/01/2007 13:31:32 Mensagens: 1266 Offline

FernandoFranzini wrote:
Defina pelo menos uma exception para cada camada.
Persistência - AcessoException
Negocio - NegocioExcetoptin
Visão - VisaoException

Na camada de visão vc pega o texto e imprime para o usuario.

Acho essa abordagem um tanto ultrapassada. Essa perspectiva leva à criação de inúmeras exceptions desnecessárias, uma para cada camada, que nada faz além de conter a lançada pela camada anterior - o que chega na camada de visão é uma exceção de visão que contém uma de negócio, que contém uma de persistência, um pacotão.

Já discuti com várias pessoas sobre a melhor forma de administrar as exceções, e até um tempo atrás, usávamos um interceptor que capturava todas as exceções - nós lançavamos e só eram pegas aquelas referentes ao comportamento do próprio sistema (LoginInvalidoException, por exemplo), as demais exceções eram tratadas por esse interceptor. Já é uma abordagem melhor, mas aí percebi que era um trabalho a mais, pois á um mecanismo nativo que faz isso: a tag error-page do web.xml (falando aqui de sistemas web, claro). Nela pode-se especificar qual exception leva para qual página de erro, assim você pode lançar as exceções de banco, de envio de email, etc, e não se preocupar em qual camada ela deve ser tratada, isso será feito na mais alta.

Flw!

This message was edited 1 time. Last update was at 28/09/2011 09:53:07

FernandoFranzini wrote:Sua exception deve ser checkada!! como vc fez?

não fiz checagem ... apenas capiturei a exception(ConstrantViolation) no método adicionar e criei uma nova exception (RegistroDuplicado) e no metodo salvar (na camada de Controller) executei o metodo adicionar onde ocorre o erro de ConstrantViolation e tentei capturar a execption que criei(RegistroDuplicado) para enviar uma mensagem personalizada para tela.

está errado esse pensamento ?

This message was edited 2 times. Last update was at 28/09/2011 10:15:39

tnaires wrote:Olá. Vou mostrar como geralmente realizo o tratamento de exceções.

[/code]
Então, quando a exceção chegar no managed bean, fazemos o tratamento necessário:
[code]class UsuarioBean {
public void criarUsuario() {
try {
usuarioService.create(login, senha);
} catch (ApplicationException ex) {
// Exibir mensagem de negócio para o usuário.
}
}
}[/code]

Acredito que fizemos diferente e chamos ao mesmo lugar no final ....

mas no final não consegui capturar a execption igual vc capturou no criarUsuario , acredito que seja pela sua validação

[code]
if(objeto.isEmpty)
throw new Exeption()
[/code]

mas como vou fazer essa validação se é erro de banco (ConstrantViolation) ?

obs : me corrija se eu estiver errado

GUJ Master Membro desde: 24/04/2009 12:58:16 Mensagens: 1541 Offline

Acho essa abordagem um tanto ultrapassada. Essa perspectiva leva à criação de inúmeras exceptions desnecessárias, uma para cada camada, que nada faz além de conter a lançada pela camada anterior - o que chega na camada de visão é uma exceção de visão que contém uma de negócio, que contém uma de persistência, um pacotão.

Pode existir aplicações que não contenham regras de negocio complexa que com uma exception genérica por camada já resolve o problema...vendo que hoje um sistema distribuído multicamadas pode chegar em 4 ou 5 camadas logicas e/ou distribuídas...sua justificativa de números de exceptions é inconsistente.

E outra, pode existir aplicações que contenham regras de negocio complexa e por isso exista a necessidade varias exception por erro de negocio....tudo esta relacionado com necessidade....justificar com algo ultrapassado tb é inconsistente...Pode não ser o seu cenário mas pode ser de milhões outros.

GUJ Master Membro desde: 15/01/2007 13:31:32 Mensagens: 1266 Offline

FernandoFranzini wrote:Pode existir aplicações que não contenham regras de negocio complexa que com uma exception genérica por camada já resolve o problema...vendo que hoje um sistema distribuído multicamadas pode chegar em 4 ou 5 camadas logicas e/ou distribuídas...sua justificativa de números de exceptions é inconsistente.

E outra, pode existir aplicações que contenham regras de negocio complexa e por isso exista a necessidade varias exception por erro de negocio....tudo esta relacionado com necessidade....justificar com algo ultrapassado tb é inconsistente...Pode não ser o seu cenário mas pode ser de milhões outros.

O caso é que exceções genéricas não fazem sentido. Lançar DaoException ou BusinessException não diz nada, o ideal seria lançar uma exceção para uma dada situação, como FundosInsufucientesException. E não importa o nível de complexidade das regras de negócio do sistema, o que importa é que as exceções sejam representativas dentro do domínio, seja simples ou não.

Acho que não fui claro no seguinte, não sou contra criar várias exceções para n situações, o que disse é que você não precisa lançar exceções de banco que devem ser pegas na camada de negócio, que vai empacotá-la com outra e mandá-la para a camada view, isso que é uma abordagem ultrapassada. Se você recebe uma SQLException ao não conseguir conectar no banco, é realmente necessário empacotá-la? Isso é que deve ser levado em consideração. Ao dizer que deve haver uma exceção genérica para cada camada, fica a clara impressão de que você precisa passar por elas quando um erro ocorre, o que não é verdade. Se a exceção deve ser tratada de uma camada para a outra (não encontrou o login), ok, sem problemas, mas uma exceção de que o banco está fora não precisa ser capturada na camada de negócio, se for apenas informar para o usuário que ele deve tentar mais tarde. Em resumo, cuidado com essas obrigatoriedades entre camadas!

Flw!

GUJ Master Membro desde: 24/04/2009 12:58:16 Mensagens: 1541 Offline

O caso é que exceções genéricas não fazem sentido. Lançar DaoException ou BusinessException não diz nada,

Logico que faz...desde que a mensagem de erro esteje clara dentro do objeto, uma vez que duas exception pode ser do mesmo tipo, com diferentes significados. Existem inúmeros casos dentro de varias especificações: JDBC, JPA etc....

Acho que não fui claro no seguinte, não sou contra criar várias exceções para n situações, o que disse é que você não precisa lançar exceções de banco que devem ser pegas na camada de negócio, que vai empacotá-la com outra e mandá-la para a camada view, isso que é uma abordagem ultrapassada. Se você recebe uma SQLException ao não conseguir conectar no banco, é realmente necessário empacotá-la?

Eu tb concordo....embora muitas produtos façam isso.... minha dica não foi para empacotar...foi para TRADUZIR e repassar outra exception em nível de serviço.

Eu entendi sim...acho muito legal sua opinião e todos crescemos com isso...eu particularmente só acho que quando vc invalidar uma opções arquitetural vc tem q ter justificativas coerentes.... cenário versus pros e contras.....

GUJ Master Membro desde: 15/01/2007 13:31:32 Mensagens: 1266 Offline

FernandoFranzini wrote:Logico que faz...desde que a mensagem de erro esteje clara dentro do objeto, uma vez que duas exception pode ser do mesmo tipo, com diferentes significados. Existem inúmeros casos dentro da própria de varias especificações JDBC, JPA etc....

Não, não faz. Não existe uma JPAException na JPA nem uma JDBCException no JDBC. Preste atenção amigo, há uma grande diferença entre SQLException e DaoException.

FernandoFranzini wrote:Eu tb concordo....embora muitas produtos façam isso.... minha dica não foi para empacotar...foi para TRADUZIR e repassar outra exception em nível de serviço.

Ainda sim, não há o que traduzir numa exceção que indica que o banco está fora. Não é porque é uma exceção gerada no banco que deve necessariamente ser traduzida para ser passada para a frente, já que o que ela representa é mais do que claro.

Notícias, artigos e o maior fórum brasileiro sobre Java