Olá,
Tenho uma dúvida sobre interação cliente/servidor no J2EE. Não sei se existe um pattern para isso, mas lá vai.
Seja um método de EJB de fachada “boolean getAlgumaCoisa(“a”,“b”)” que faz qualquer coisa (na verdade ele pode até chamar outros n EJBs). Digamos que o cliente o chamou e, devido algum problema, uma exceção ocorreu (e foi logada no servidor com o log4j) e o método retornou “false” para o cliente.
Agora, como o cliente sabe que exceção ocorreu? Como ele exibe um retorno para o cliente? Não posso simplesmente exibir "Caro usuário, um problema ocorreu na execução do seu método. Tente novamente ou vá tomar um café."
Enfim, o cliente não tem como saber se foi uma exceção que ocorreu (e nesse caso qual foi?!) ou se simplesmente o método retornou false porque violou uma regra de negócio.
Afinal, qual a forma correta de tratar isso? Como o cliente “descobrir” o que aconteceu no servidor?
Pensei em usar JMS, mas com certeza essa será minha última tentativa…
Ah, e outra coisa, alguém conhece um meio de automatizar o processo de criação (e uso) do padrão “business delegate”? É um “sac…” criar um método de negócio num ejb, criar um método quase igual no ejb de fachada, mais outro na classe de delegate e finalmente chamar isso em um evento de tela em uma action do struts…
Quanto ao tratamento exceções, o correto é vc extender as exception do java e utilizando assim em sua aplicação exception de aplicação.
Ex.: Para exception ocorrida na camada DAO ->
DAOException que extende Exception ou SQLException. Essa pode ter outras especializações como SaveException ou LoadException.
Assim vc pode criar outras para tratar de exception relacionadas a negócios ou validação.
O comum é vc ter uma exception que identifique sua aplicação e todas essas outras citadas que a especializam.
Quanto a geração de código, vc pode dar uma olhada em velocity. Esse é show e de fácil utilização.
Ok JavaBaby,
Eu tenho minhas exceptions customizadas, mas se o método ejb retorna sempre um “boolean” para o cliente, como o cliente consegue obter “a causa” do “false” na execução do seu método. Em outras palavras, ele teria que ir ateh o container j2ee e pedir por ela? E como o container saberia qual cliente que invocou o metodo em qual ejb em que momento?
Ou seja, o esquema das exceptions eu ja estou usando, mas como mandar isso pro cliente?
pcalcado
Mandando, ué. Envie suas exceções de negócio para o cliente.
E leia o link que o LIPE passou.
[]s
R
rocket
Eu li o link…
Mas isso é, no mínimo, fétido como diria um colega meu.
Quando programávamos em Delphi (bons tempos), cada exceção tinha um código e uma tabela de resolução. Assim, quando um erro ocorria no serviço, este era armazenado lá. O cliente, com o ID do erro verificava a mensagem a ser exibida e outras coisas (help, encaminhamento, reentrancia, etc.)
Se o cliente tiver que capturar exceções também, vou ter que propagar essas classes de exceções por todas as camadas! Isso é deprimente, mas tudo bem…
Até e obrigado pela ajuda. Ah, o link foi muito esclarecedor, mas deu pra notar que o esquema de gerenciamento de erros no J2EE não é nenhuma maravilha…
Abraços.
TedLoprao
E aí Rocket, seguinte velho, eu juro que não entendi seu ponto de vista… Primeiro, se minha camada não é capaz de tratar a exceção, lógicamente eu tenho que passá-la para a camada seguinte, na verdade não consigo ver onde vc não faria isso… Mesmo que seu controle de erros fosse de outra forma, essa seria a saída mais lógica e correta para o problema…
Quanto ao problema de passar para o cliente um código vinculado a uma mensagem previamente cadastrada, cabe a vc implementar esta solução se assim for necessário… Basta customizar suas exceções e colocar um código de erro nelas, por exemplo…
Por que vc chama isso de fétido?? Sinceramente, acho q se determinado erro ocorreu o fato deve ser notificado!!!
Fallow
pcalcado
Pois é, bons tempos do Delphi…quando você não programava OO e ficava passando códigos de cima para baixo.
Note que até mesmo o Delphi tem tratamento de exceções, e como o Ted falou, as exceções devem seguir o fluxo de camadas. Você pdoe facilmente retornar uma exceção com um código e usar uma tabela, uma tabela nu cliente, outra no servidor. É claro que você poderia usar uma exceção personalizada com todos os seus benefícios, mas se você acha que passar códigos é mais interessante, fique á vontade, replicando informação e fazendo código procedural.
Cada um programa do jeito que acha mais fácil…
[]s
A
Anonymous
Oi,
Este post tah se direcionando prum lado meio pessoal, mas tudo bem, viva as diferencas.
Desde as epocas do delphi (e antes vb) desenvolviamos sistemas usando recursos OO; tambem sou totalmente contra codigo procedural, embora ele seja (e sera ainda) a maioria por muito tempo…
Sobre as excecoes simplesmente acho muito codigo ficar colocando “throws” isso “throws” aquilo em varias camadas. Ja nao chega um “throws RemoteException” para todo mundo?! E como o proprio artigo da ibm comenta, eh dificil saber quando a excecao ja foi tratada ou nao, sem contar a sobrecarga de excecoes em operacoes tipo criar ejb, obter ejb, usar servicelocator, instanciar camada de persistencia, encapsular dados, etc…
Abraco a todos.
TedLoprao
Sinceramente, eu não vejo isso…
Mas vc não concorda que se pode ocorrer um erro ele deve ser tratado? Tudo bem, no Delphi vc não é obrigado a tratar todas as exceções que possam vir a acontecer (maldito erro que esqueci de tratar :lol: ), mas até onde isso pode ser realmente bom ? Me poupa código? :roll:
Eu acho q, como o pcalcado colocou, cada um programa da maneira q lhe convém, vc pode muito bem fazer um facade (ou algo parecido) que simplesmente ignore qualquer exception e trate os erros através do retorno dos métodos (como vc fazia com Delphi ou sei lá o q)…
[MOMENTO DESCONTRACAO ON]
Só não retruque se alguém disser que seu código está meio fétido, hehehe
[MOMENTO DESCONTRACAO OFF]
Fallow
pcalcado
Vou colar o texto que enviei ontem para uma lsita de discussão, acho que esclarece alguma coisa :
Supondo que sua fachada tenha um método inserirUsuario(Usuario u), você porcessa tudo bem, até que o DAO receba um erro do banco. Ele pega a maldita SQLException e transforma numa…uhm… ErroPersistenciaException, passando para quem o chamou. A Façade capta o erro e o encapsula em um uhm… UsuarioException, que é passada ao cliente.
