Checked e unchecked exceptions nas camadas

GUJ Expert Membro desde: 18/02/2008 16:17:53 Mensagens: 3002 Offline

Lendo o Mundo Java 33, sobre EJBs e Spring, na parte de controle de transações, fala que ambas as tecnologias fazem rollback da transação quando encontram unchecked exceptions, mas com as checked deixam rolar, supõem que o desenvolvedor queria que isso aconteça.

Fiquei pensando no caso de uma exceção na camada de persistência, como uma SQL ou IOException, normalmente não são esperadas pela aplicação.

A camada deveria tratar esses erros e transformá-los em erros do sistema quando a requisição voltar para a camada que a chamou? Acho meio infeliz dar um catch e um throw logo depois só pra transformar a exceção. O que tem de "checado" numa exceção dessas?

JWizard Membro desde: 23/02/2007 15:52:55 Mensagens: 2034 Offline

Bruno Laturner wrote:Lendo o Mundo Java 33, sobre EJBs e Spring, na parte de controle de transações, fala que ambas as tecnologias fazem rollback da transação quando encontram unchecked exceptions, mas com as checked deixam rolar, supõem que o desenvolvedor queria que isso aconteça.

Fiquei pensando no caso de uma exceção na camada de persistência, como uma SQL ou IOException, normalmente não são esperadas pela aplicação.

A camada deveria tratar esses erros e transformá-los em erros do sistema quando a requisição voltar para a camada que a chamou? Acho meio infeliz dar um catch e um throw logo depois só pra transformar a exceção. O que tem de "checado" numa exceção dessas?

oi

aqui o cara que organizou o tratamento de excessões pensou que devemos sempre tratar todas as excessões checked possíveis e só em ultimo caso lançar uma unchecked

por exemplo, na camada DAO, eu teria algo assim

assim eu consigo garantir que se um runtime ocorrer é porque eu não encontrei a entidade ou ela não era única.. na minha opinião, quanto menos unchecked você retornar, principalmente para uma aplicação J2EE, melhor

abs

Bruno Laturner wrote:O que tem de "checado" numa exceção dessas?

Olá Bruno,

Esse é um bom ponto. Muitos consideram que essas exceptions (SQL, IO, por exemplo), não deveriam ser checadas. É um erro de projeto da linguagem.

Por isso, somos praticamente obrigados a fazer o que você falou. Tratar para transformar.

[]´s

GUJ Expert Membro desde: 18/02/2008 16:17:53 Mensagens: 3002 Offline

rodrigo_gomes wrote:

Bruno Laturner wrote:O que tem de "checado" numa exceção dessas?

Olá Bruno,

Esse é um bom ponto. Muitos consideram que essas exceptions (SQL, IO, por exemplo), não deveriam ser checadas. É um erro de projeto da linguagem.

Por isso, somos praticamente obrigados a fazer o que você falou. Tratar para transformar.

[]´s

É, tava pensando a mesma coisa, erro de projeto. Antes de ver a revista já até tinha lido um pouco sobre o assunto, em especial a Trilogia de Tratamento das exceções no Java do Luca (Parte 1 - Parte 2 - Parte 3).

É... complicado.

O Sérgio também tem vários artigos:
Exceções: Conceitos
Exceções: Boas práticas, más práticas
Exceções: Classe Utilitárias

Li um pouco na parte de Boas práticas, em Camadas e exceções

O cliente da camada deverá analizar a exceção que recebe, e traduzir essas exceção para um dos tipos de exceção da sua camada. Isto só deverá ser feito se a camada não sabe como resolver o problema apresentado pela camada inferior.

Bem, é a regra de que cada camada sabe tratar o que vem de baixo, seja retorno ou exceção, enquanto a que tá em baixo nem sabe que a de cima existe, então mesmo junto com essas novas regras de un/checked exceptions que outros frameworks usam, parece que tem q tratar tudo. Ou pelo menos transformar mesmo.

Java Ninja Membro desde: 31/01/2003 10:21:32 Mensagens: 260 Offline

Um ou dois tostões sobre o assunto...

http://leandrosilva.com.br/2008/08/12/cuidado-com-suas-excecoes

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

Bruno Laturner wrote:

O Sérgio também tem vários artigos:
Exceções: Conceitos
Exceções: Boas práticas, más práticas
Exceções: Classe Utilitárias

Li um pouco na parte de Boas práticas, em Camadas e exceções

O cliente da camada deverá analizar a exceção que recebe, e traduzir essas exceção para um dos tipos de exceção da sua camada. Isto só deverá ser feito se a camada não sabe como resolver o problema apresentado pela camada inferior.

Bem, é a regra de que cada camada sabe tratar o que vem de baixo, seja retorno ou exceção, enquanto a que está em baixo nem sabe que a de cima existe, então mesmo junto com essas novas regras de un/checked exceptions que outros frameworks usam, parece que tem q tratar tudo. Ou pelo menos transformar mesmo.

Em inglês existe o termo "handle" (manipular) que é diferente de resolver.
Quando uma camada recebe uma exceção da camada inferior que ela não sabe resolver, mesmo assim ela têm que a manipular (handle). Em bom protugues, ela tem que fazer o try-catch. Mas isso apenas para a encapsular em uma outra Exceção da própria camada.

Por exemplo, quando vc comunica com o banco de dados via jdbc a exceção que é retornada é SQLException, sempre. Mesmo quando o erro é um IOException ( por exemplo, connectino timeout).

A dificuldade do encapsulamento advém do fato que simplesmente jogar todas as exceções das camadas inferirors no mesmo bolo não ajuda nada. ( por exemplo um SQLException de "sem conexão" deveria ser um exception de uma classe filha de SQLException). Seguindo a boa prática "Seja especifico" vc deve encapsular as exceções mais baixas em exceções da camada mas de forma categorizada. Todas elas herdam da exceção "mãe" da camada mas são mais especificas.

Por exemplo, numa camada de acesso a dados genérica poderíamos ter a exceção mae "DataAcessException" e como filhas poderíamos ter "ConnectionException" , "DatabaseNotFoundException" , "AutenticationException" , "DuplicateRegistryException" e "ConcurrencyException". Todas elas são DataAcessException, mas todas significam erros de categorias diferentes.

finalmente as classe de exceção mãe deve ser filha de RuntimeException. Apenas deve ser filha de Exception se a camada representa algum subsistema fora do escopo da aplicação. ( por exemplo IOException é checked porque representa o o subsistema de arquivos do OS e a SQLException o subsistema de banco de dados)

Eu sou daqueles que acham que as Checked Exceptions do Java nunca deveriam existir pois mais atrapalham que ajudam. De qualquer forma isso é opinião e há controvérsias.

Emerson Macedo wrote:Eu sou daqueles que acham que as Checked Exceptions do Java nunca deveriam existir pois mais atrapalham que ajudam. De qualquer forma isso é opinião e há controvérsias.

Eu discordo. Acho que checked exceptions são importantes, apenas foram usadas da forma errada desde o começo da linguagem.

Há uma RFE que acho legal atacando exatamente este problema da linguagem:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6534270

victorwss wrote:...
Eu discordo. Acho que checked exceptions são importantes, apenas foram usadas da forma errada desde o começo da linguagem.
...

Concordo plenamente!

O pessoal usa certas coisas de maneira exagerada/errada e com isso aquilo que foi usado dessa forma é visto como uma porcaria, etc

This message was edited 1 time. Last update was at 05/02/2009 12:55:59

victorwss wrote:

Emerson Macedo wrote:Eu sou daqueles que acham que as Checked Exceptions do Java nunca deveriam existir pois mais atrapalham que ajudam. De qualquer forma isso é opinião e há controvérsias.

Eu discordo. Acho que checked exceptions são importantes, apenas foram usadas da forma errada desde o começo da linguagem.

Há uma RFE que acho legal atacando exatamente este problema da linguagem:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6534270

Se você acha tão importante, apresente aqui um exemplo de uma situação que não seja possível resolver com unchecked exceptions ou seja necessário muito trabalho para alcançar o mesmo resultado.

ASOBrasil wrote:

victorwss wrote:...
Eu discordo. Acho que checked exceptions são importantes, apenas foram usadas da forma errada desde o começo da linguagem.
...

Concordo plenamente!

O pessoal usa certas coisas de maneira exagerada/errada e com isso aquilo que foi usado dessa forma é visto como uma porcaria, etc

A questão aqui não foi usar de maneira errada, o que eu concordo que aconteceu bastante, mas a questão é que é inútil a existência das checked exceptions, mais uma vez na minha opinião. Caso você ache o contrário, apresente algum bom argumento para tal, assim como pedi ao colega acima.

E pra finalizar, eu posso tratar uma unchecked exception se eu quiser, eu só não sou forçado a faze-lo ....

[]s

Se você acha tão importante, apresente aqui um exemplo de uma situação que não seja possível resolver com unchecked exceptions ou seja necessário muito trabalho para alcançar o mesmo resultado.

Ok, como vc lidaria se SQLException fosse unchecked?

This message was edited 2 times. Last update was at 05/02/2009 13:23:16

Emerson Macedo wrote:...

Quer um bom argumento!? Um exemplo!? Então vamos lá:

Que tal o InvocationTargetException dos métodos de reflection? Qualquer método chamdo por reflection pode lançar uma exceção, e simplesmente lançá-la para cima de qualquer jeito pode ser desastroso (afinal, você normalmente não sabe o que significa essa exceção). Assumir que o método nunca falhará normalmente significa uma falha de projeto, logo nada mais normal do que ser obrigado a tratar a exceção.

Um outro exemplo (usando aquela cláusula suppresses sugerida na RFE):

This message was edited 1 time. Last update was at 05/02/2009 13:42:23

peczenyj wrote:

Se você acha tão importante, apresente aqui um exemplo de uma situação que não seja possível resolver com unchecked exceptions ou seja necessário muito trabalho para alcançar o mesmo resultado.

Ok, como vc lidaria se SQLException fosse unchecked?

Já experimentou um Try-Cath? Bem basico e funciona que é uma beleza.

victorwss wrote:...

Você não acha mais simples tratar o que for necessário, ao invés de tentar ignorar o que você não quer tratar?

Emerson Macedo wrote:

peczenyj wrote:

Se você acha tão importante, apresente aqui um exemplo de uma situação que não seja possível resolver com unchecked exceptions ou seja necessário muito trabalho para alcançar o mesmo resultado.

Ok, como vc lidaria se SQLException fosse unchecked?

Já experimentou um Try-Cath? Bem basico e funciona que é uma beleza.

Sim, mas ai eu opto por faze-lo: o compilador não me obriga.

This message was edited 2 times. Last update was at 05/02/2009 13:57:24

peczenyj wrote:

Emerson Macedo wrote:

peczenyj wrote:

Se você acha tão importante, apresente aqui um exemplo de uma situação que não seja possível resolver com unchecked exceptions ou seja necessário muito trabalho para alcançar o mesmo resultado.

Ok, como vc lidaria se SQLException fosse unchecked?

Já experimentou um Try-Cath? Bem basico e funciona que é uma beleza.

Sim, mas ai eu opto por faze-lo: o compilador não me obriga.

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).

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