Checked e unchecked exceptions nas camadas

Mas nesse caso o objeto A sabe do comportamento do objeto B pelo contrato e B parece ser incapaz de tratar um eventual erro, sem falar que B poderia ser, então, refatorado para B' e trabalhar como vc achar melhor. Enfim é só uma observação.

This message was edited 1 time. Last update was at 05/02/2009 14:21:04

Sim, eu entendi o que você quis dizer, mas qual seria o outro caso?

Emerson Macedo wrote:...
Vamos imaginar a seguinte cenário:
- Objeto A envia uma mensagem ao Objeto B.
- Objeto B retorna uma exception para o Objeto A como resposta a sua mensagem.

Eu suponho que o Objeto A que tenha a noção se esse erro ele quer/vai/precisa tratar de alguma forma. Portanto, me parece mais lógico que ele não seja obrigado a tratar. Caso contrário, O Objeto que recebeu a mensagem (no caso Objeto B) está tomando uma decisão que não lhe cabe(ou se preferir, o Objeto B está impondo uma decisão ao Objeto A).

Exatamente como o peczenyj falou, você coloca checked exceptions se você quiser! E se eu definir que o método que chamar a minha implementação deva tratar aquela exception então eu posso definir explicitamente e pronto! Entendeu que o negócio é opcional? A linguagem é aberta para isso e ela permite que cada pessoa trabalhe da maneira que achar melhor. Assim como você pode deixar tudo como "unchecked" porque você acha que é a melhor solução.

peczenyj wrote:
Ok, como vc lidaria se SQLException fosse unchecked?

SQLException é um típico caso em que a API não foi bem projetada. Erros como SQLException, HibernateException, IOException, e etc são erros que não tem como ser remediado e geralmente o usuário do sistema não tem controle sobre a situação que gerou o erro, diferente de DataDeVencimentoInvalidaException ou DataSelecionaEhDiaUtilException (nome horrivel, eu admito).

Checked exceptions não devem ser tratadas na maioria dos casos, se você esta num ambiente "gerenciado" deixe seu application server\servlet container logar a exceção, configure o logger do servidor de forma correta e coerente com a forma como sua equipe lida com erros em produção e mostre uma tela de erro feliz para o usuário.

ASOBrasil wrote:

Emerson Macedo wrote:...
Vamos imaginar a seguinte cenário:
- Objeto A envia uma mensagem ao Objeto B.
- Objeto B retorna uma exception para o Objeto A como resposta a sua mensagem.

Eu suponho que o Objeto A que tenha a noção se esse erro ele quer/vai/precisa tratar de alguma forma. Portanto, me parece mais lógico que ele não seja obrigado a tratar. Caso contrário, O Objeto que recebeu a mensagem (no caso Objeto B) está tomando uma decisão que não lhe cabe(ou se preferir, o Objeto B está impondo uma decisão ao Objeto A).

Exatamente como o peczenyj falou, você coloca checked exceptions se você quiser! E se eu definir que o método que chamar a minha implementação deva tratar aquela exception então eu posso definir explicitamente e pronto! Entendeu que o negócio é opcional? A linguagem é aberta para isso e ela permite que cada pessoa trabalhe da maneira que achar melhor. Assim como você pode deixar tudo como "unchecked" porque você acha que é a melhor solução.

Curioso é você definir que quem manda mensagem para teu objeto deva tratar alguma coisa. Eu acho isso péssimo. Acho muito mais lógico eu notifica-lo que algum problema aconteceu (i.e. lançando uma exception) e ele decidir qual ação vai tomar dado a mensagem de retorno. É o caso da SQLException. Quem a criou "definou" que agente tinha que tratar e no final das contas agente viu no que deu.

This message was edited 1 time. Last update was at 05/02/2009 15:45:51

Emerson Macedo wrote:...
Curioso é você definir que quem manda mensagem para teu objeto deva tratar alguma coisa. Eu acho isso péssimo. Acho muito mais lógico eu notifica-lo que algum problema aconteceu (i.e. lançando uma exception) e ele decidir qual ação vai tomar dado a mensagem de retorno. É o caso da SQLException. Quem a criou "definou" que agente tinha que tratar e no final das contas agente viu no que deu.

Acho que nossa discussão entrou em um loop aqui.

Concordo com o que o Rubem disse. SQLException não é um bom exemplo e não acho que deve ser uma checked exception.

Emerson Macedo wrote:
Curioso é você definir que quem manda mensagem para teu objeto deva tratar alguma coisa. Eu acho isso péssimo. Acho muito mais lógico eu notifica-lo que algum problema aconteceu (i.e. lançando uma exception) e ele decidir qual ação vai tomar dado a mensagem de retorno. É o caso da SQLException. Quem a criou "definou" que agente tinha que tratar e no final das contas agente viu no que deu.

Hum, tem o outro lado da moeda também... Por um lado checked exceptions tira a liberdade de quem usa a classe pois obriga a tratar a excessão, por outro lado se não tiver checked exceptions o autor da classe não tem nenhum mecanismo para obrigar quem usa a sua classe a tratar uma determinada excessão que ele julga importante ser tratada.

O negócio é o seguinte:

Método A pode lançar exception X ocasionalmente. Vamos supor que o lançamento de X não corresponde a um erro de programação e nem a alguma falha catastrófica irrecuperável e que seja algo que possa ser efetivamente tratado de uma forma que não seja simplesmente "gere um log" ou "mostre uma mensagem para o usuário". Ou seja, algo que cai bem no conceito de uma exceção verificada.

Chamar o método A e não tratar um possível X é um erro de programação. Logo, seria bom que o compilador te forçasse a tratar.

Por outro lado, se X for unchecked, é muito fácil se esquecer de tratar X corretamente. E isso é muito pior do que ter que encapsular em outras exceções ou coisas assim.

Ou pior, vamos supor que você pode ter DataDeVencimentoInvalidaException sugerido pelo Rubem. Vamos supor que ela é unchecked, daí você chama um método que lança esse troço e você nem sabia que isso podia ser lançado.

Exceções não checadas correspondem a falhas catastróficas e erros de programação. As outras, devem ser tratadas adequadamente, mesmo que isso exija cláusulas catch bem chatas e repetitivas. Se não houvesse checked exceptions, mesmo as falhas normais e esperadas poderiam compremeter a aplicação por não serem tratadas corretamente. E frequentemente vemos problemas por ter exceções que são esperadas serem empacotadas em unchecked exception ou herdarem de RuntimeException.

C# não tem checked exception. Lá é comum o problema do tipo "ué, eu não sabia que esse método podia lançar essa exceção."

This message was edited 2 times. Last update was at 06/02/2009 09:44:10

Rubem Azenha wrote:

Emerson Macedo wrote:
Curioso é você definir que quem manda mensagem para teu objeto deva tratar alguma coisa. Eu acho isso péssimo. Acho muito mais lógico eu notifica-lo que algum problema aconteceu (i.e. lançando uma exception) e ele decidir qual ação vai tomar dado a mensagem de retorno. É o caso da SQLException. Quem a criou "definou" que agente tinha que tratar e no final das contas agente viu no que deu.

Hum, tem o outro lado da moeda também... Por um lado checked exceptions tira a liberdade de quem usa a classe pois obriga a tratar a excessão, por outro lado se não tiver checked exceptions o autor da classe não tem nenhum mecanismo para obrigar quem usa a sua classe a tratar uma determinada excessão que ele julga importante ser tratada.

Realmente entramos em loop. Você acha que um objeto pode obrigar seu cliente a tratar uma exception. Eu já acho que o cliente que mandou a mensagem ao objeto e recebeu esse retorno deve decidir o que fazer.

victorwss wrote:Por outro lado, se X for unchecked, é muito fácil se esquecer de tratar X corretamente. E isso é muito pior do que ter que encapsular em outras exceções ou coisas assim.

Se você tiver testes automatizados (e.g. unitarios, integrados e funcionais), certamente não se esquecerá de tratar quando for necessário.

Emerson Macedo wrote:

victorwss wrote:Por outro lado, se X for unchecked, é muito fácil se esquecer de tratar X corretamente. E isso é muito pior do que ter que encapsular em outras exceções ou coisas assim.

Se você tiver testes automatizados (e.g. unitarios, integrados e funcionais), certamente não se esquecerá de tratar quando for necessário.

Seguindo isso que você disse, poderíamos tirar todas as verificações de corretude que o compilador faz e deixar tudo isso ao cargo do programador e de seus testes unitários/funcionais/whatever.

Emerson Macedo wrote:
Realmente entramos em loop. Você acha que um objeto pode obrigar seu cliente a tratar uma exception. Eu já acho que o cliente que mandou a mensagem ao objeto e recebeu esse retorno deve decidir o que fazer.

Aí é que esta a beleza da computação

Eu prefiro ter X e eu preferir não usar X do que eu querer usar X mas não poder usar X por que a linguagem não tem X.

Emerson Macedo wrote:Se você tiver testes automatizados (e.g. unitarios, integrados e funcionais), certamente não se esquecerá de tratar quando for necessário.

Depende... ter testes não garante que o teste faz a validação adequada.
Concordo que de forma alguma checked exceptions substituem ou diminuem a importância de testes, mas elas pelo menos dão um feedback mais rápido.

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

Rubem Azenha wrote:

peczenyj wrote:
Ok, como vc lidaria se SQLException fosse unchecked?

SQLException é um típico caso em que a API não foi bem projetada. Erros como SQLException, HibernateException, IOException, e etc são erros que não tem como ser remediado e geralmente o usuário do sistema não tem controle sobre a situação que gerou o erro, diferente de DataDeVencimentoInvalidaException ou DataSelecionaEhDiaUtilException (nome horrivel, eu admito).

Remediar o problema não tem nada a haver com ser verificada ou não. Não é porque a exceção é verificada que significa que vc pode resolver o problemas. E também não é verdade em exceções não-verificadas.

A diferença entre os dois tipos é conceptual, logo não faz sentido discutir se seria possivel usar java apenas com exceções não-verificadas. É possivel. Tanto é possivel que exceções verificadas só existem em java. Em outras linguagens ninguem sabe o que é isso.

Exceções verificadas são uteis porque obrigam o caller ( quem chama o método) a lidar ( handle, manipular) com a exceção explicitamente. Ou seja, o programador não tem como não saber que ali ha o lançamento de uma exceção.
Isto é particularmente util quando vc está criando frameworks e /ou API de camada. Quando o caller invoca a camada /framework ele perde o controlo. Nesse caso a camada abaixo tem que vigiar que é bem usada. Tal como um método verifica se argumentos não são nulos e estão dentro do esperado, também o mesmo tem que ser feito para exceções. Este tipo de API tem que forçar o caller a lidar com a exceção de forma que lidar com a exceção faz parte do contrato. É chato é, mas é util ? sim. muito. Não tem como vc se esquecer de lidar com a exceção.

Agora, lidar e resolver são coisas diferentes. O caller pode não saber resolver o problema. Nesse caso ele passará a exceção adiante. Mas agora ele é livre de dar tratamento À exceção. Por exemplo, encapsulando-a numa exceção não-verificada.

As API SQL , IO , Threads e Reflection não são mal projetadas. Isso é um mito levantado e alimentado por quem não sabe trabalhar com exceções. Elas usam exceções verificadas porque são API que ao serem chamadas o programador perde o controlo do que acontece ( aka, são chamadas "nativas" ).

As exceções do Hibernate ou do EJB poderiam não ser verificadas. Ai éuma decisão de design, mas não podemos censurar a escolha de usar exceções verificadas só porque temos preguiça de lidar com elas.

Na realidade , porque a maioria dos programadores não divide o programa em camadas , têm que lidar com exceções veirifcadas em todo o lugar da aplicação ( tipo tratar um SQLException dentro de um component siwing). Esse é que é o problema e não as exceções serem verificadas. Se encapsular o uso de SQL em uma camada, de arquivos em uma camada , de reflectino ,etc.. nunca mais vai ter problemas com exceções verificadas.

As exceções verificadas são essenciais para um bom design da aplicação, especialmente se ela for um API de uso genérico.
Sem elas é possivel utilizar as mesmas funções da API mas com uma garantia a menos.

Na época em que querem criar anotações @NotNull para verificação automática da passagem de nulos não autorizados, não faz sentido apoiar a ideia de que exceções verificadas são inuteis. Quando mais facilidades existirem para construir bons designs de forma elegante, melhor.

Não digam que a API de SQL foi mal projetada porque usa exceções verificadas que isso pega mal. Ela foi mal projetada sim, mas em outros pontos. Por exemplo, falta de hierarquia de exceções mais fina (embora isso esteja sendo solucionado).

This message was edited 1 time. Last update was at 06/02/2009 12:33:30

victorwss wrote:

Emerson Macedo wrote:

victorwss wrote:Por outro lado, se X for unchecked, é muito fácil se esquecer de tratar X corretamente. E isso é muito pior do que ter que encapsular em outras exceções ou coisas assim.

Se você tiver testes automatizados (e.g. unitarios, integrados e funcionais), certamente não se esquecerá de tratar quando for necessário.

Seguindo isso que você disse, poderíamos tirar todas as verificações de corretude que o compilador faz e deixar tudo isso ao cargo do programador e de seus testes unitários/funcionais/whatever.

Isso não tem nada ver com que eu disse, apesar de poder ser aplicado em alguns casos como na utilização de linguagens de tipagem dinâmica (neste caso o compilador não verifica os tipos). Mas voltando o que eu havia dito, se você fizer bons testes automatizados, provavelmente você vai testar os fluxos que você espera em cada caso.

Rubem Azenha wrote:

Emerson Macedo wrote:Se você tiver testes automatizados (e.g. unitarios, integrados e funcionais), certamente não se esquecerá de tratar quando for necessário.

Depende... ter testes não garante que o teste faz a validação adequada.
Concordo que de forma alguma checked exceptions substituem ou diminuem a importância de testes, mas elas pelo menos dão um feedback mais rápido.

Ter bons testes e uma boa cobertura destes te dá uma boa garantia. Quanto ao feedback mais rápido é questionável. Eu acredito que usando uma abordagem TDD meu feedback vem mais rápido através dos testes.

Então como vcs tratariam IOException? querendo ou não estamos sujeitos a erros inesperados o mesmo se aplica ao SQLException.
Semana passada tive um erro bem chato, o desenvolvedor definiu o limite da sequence em 999 e os campos que sâo alimentados pela sequence numeric(3) chegou um belo dia que chegamos no numero magico 1000 e desenvolvedor não tratou esta situação e o incrivel que driver da oracle tbm não tratava essa situação não lançava um "ORA:0XXX".

Se tivesse tratado pelo menos com um SQLException a exceção seria mais obvia não igual a esta abaixo:
Erro da sequence

Erro do sistema: null
com.a.AException
	at com.a.ejbBase.ejbStoreBase(ejbBase.java:331)
	at applications.avaliacaoPd.Projeto.ejbStore(Projeto.java:282)
	at applications.avaliacaoPd.admin.AvaliacaoAdmin.doGet(AvaliacaoAdmin.java:190)
	at applications.avaliacaoPd.admin.AvaliacaoAdmin.doPost(AvaliacaoAdmin.java:39)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
	at com.a.ServletBase.service(ServletBase.java:78)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
	at org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:404)
	at org.apache.tomcat.core.Handler.service(Handler.java:286)
	at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372)
	at org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:797)
	at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743)
	at org.apache.tomcat.service.connector.Ajp12ConnectionHandler.processConnection(Ajp12ConnectionHandler.java:166)
	at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416)
	at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:498)
	at java.lang.Thread.run(Thread.java:534)

Tbm concordo com opinião do Victor, acho que as exceções checked são utilizadas de forma errada.

This message was edited 1 time. Last update was at 06/02/2009 12:46:16

ramilani12 wrote:Então como vcs tratariam IOException? querendo ou não estamos sujeitos a erros inesperados o mesmo se aplica ao SQLException.
Semana passada tive um erro bem chato, o desenvolvedor definiu o limite da sequence em 999 e os campos que sâo alimentados pela sequence numeric(3) chegou um belo dia que chegamos no numero magico 1000 e desenvolvedor não tratou esta situação e o incrivel que driver da oracle tbm não tratava essa situação não lançava um "ORA:0XXX".

...

Tbm concordo com opinião do Victor, acho que as exceções checked são utilizadas de forma errada.

Partindo desse princípio que você disse, todas as exceptions deveriam ser checked pra não haver erros inesperados ...
No mínimo seu sistema deve ter um tratador na última camada antes da apresentação que logue esse erro e apresente uma mensagem amigável para o usuário. A partir do conhecimento desse "novo erro inesperado", você pode avaliar se precisa alterar seu sistema para trata-lo de alguma forma ou se esse tipo de erro não será possível ser tratado e o melhor a fazer mesmo é o descrito anteriormente.

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