Desenvolvimento Web, Design

Exceções: “checked ou unchecked – Eis a questão!”

Você é designado para procurar um bug num sistema super importante onde você trabalha. Ao ler o código, você percebe um trecho assim:


try {
    controladorUsuario.salvar(diretor);
 }
 catch(Exception e) {}

E agora? Largo tudo, ligo pra minha mãe dizendo que a amo e me jogo da varanda? Calma, ainda não. Você, como bom programador deve consertar o código primeiro. Pensando em como as exceções são tratadas de forma desordenada nos sistemas legados que eu já trabalhei/já fiz, resolvi pesquisar mais sobre a forma correta de se tratar erros/exceções nos nossos  sistema. Há tempos já vinha pensando sobre o assunto e resolvi escrever no blog agora, como uma forma de difundir essas técnicas. Neste post, eu dou algumas dicas e conceitos sobre exceções que pude coletar em alguns livros de peso na área de desenvolvimento de Software. Aí vão elas:

Checked ou unchecked?

Primeiramente, vamos aprender/rever o conceito de exceções checked (checadas) e unchecked (não checadas) que servirão de base para alguns argumentos mais a frente neste post.

Checked:  São exceções que obrigatoriamente devem ser tratadas de alguma forma. Ou seja, o programador é obrigado a fazer algo com ela – tratar com um bloco try-catch (e suas combinações) ou relançar com throws na assinatura do método. Note que esse tipo de exceção não existe na maioria das linguagens. Por exemplo, Ruby e C# não possuem o conceito de checked exceptions.

Unchecked: São exceções que o programador não é obrigado a tratar.  Elas podem ser tratadas, mas o ponto é que isto não é obrigatório! Caso não sejam tratadas,  são automaticamente relançadas para a camada acima até achar alguém em alguma camada que a trate – em última instância, o erro é lançado na tela ou pior, estoura silenciosamente e pára. Em Java, essas exceções são subclasses de RuntimeException (exceções de tempo de execução).

Ok então. Mas, qual das duas usar? “Se a maioria das linguagens não tem exceções checadas, é porque não são realmente muito importantes” você talvez pense.  Esse é um assunto que dá muito pano pra manga e vários escritores técnicos bem reconhecidos já opinaram sobre isso. Alguns contra, outros a favor. Mas, gosto de ver pelo seguinte ponto de vista: Isso depende muito do que você quer. Pense por um momento no conceito de capturar exceções. É uma chance que o programador tem de se recuperar de uma falha na execução do programa. Quando você lança uma exceção checada, você está na verdade deixando bem explícito pra quem for cliente do seu código que ele tem sim uma chance de se recuperar da falha que ocorreu.  Por exemplo, ao tentar sacar R$50,00 numa conta com R$10,00 de saldo, você deve lançar algo do tipo SaldoInsuficienteException – checada. Dessa forma, não tem perigo de o programador deixar essa falha vazar para a camada acima e você o dá a chance de redirecionar o usuário para uma página de erro mais amigável. Agora, caso haja um incêndio no prédio onde o seu banco de dados está e nessa mesma hora o usuário tentou persistir um novo saldo, o que fazer? Bom, não tem como se recuperar, tem? Normalmente não.  Você não quer obrigar o programador a tratar um erro que não tem mais o que fazer, quer? Então lance uma exceção unchecked. São justamente essas 2 perguntas que você deve se fazer. “Existe uma chance de se recuperar da falha? ” e/ou “Quero dar uma chance de se recuperar dessa falha?”. É por isso que exceções como a famosa NullPointerException são não-checadas. Mesmo que você trate dentro do bloco catch para que o procedimento seja repetido ou algo assim, não vai mudar o fato que você está tentando acessar uma referência nula. Simplesmente ocorreu um erro de programação.

Cada um no seu quadrado

É importante respeitar o nível de abstração dos seus componentes. Tipo,  você já deve ter visto algo como (assuma que essa essa exceção é checked):


class TelaSalvarConta {

...

    try {

        conta.salvar();

   }

    catch(ConcurrentSerializationException exc) {...}

Aqui temos uma classe de alto nível manipulando um objeto de domínio e lançando uma exceção de baixíssimo nível. Isso é uma exposição indevida de seus objetos e significa que você quebrou o encapsulamento violentamente. Essa exceção deve ter vindo de há muito tempo sendo relançada pela própria API  até chegar a camada mais alta do sistema. Isso significa que a assinatura do método salvar() da classe Conta tem uma exceção (throws) com esse mesmo nome: ConcurrentSerializationException. Absurdo, não? Isso jamais devia ter acontecido. Em algum ponto, algum programador da API deveria ter feito:


catch(ConcurrentSerializationException exc) {

    throw new ObjectAlreadyInTransactionException(exc);

}

Sendo ObjectAlreadyInTransactionException uma exceção não-checada, não seria necessário o programador declarar uma exceção na assinatura do método, além disso, se ele desejar tratar essa exceção mesmo sem ser obrigado a isso, ele tem uma exceção mais próxima da camada de negócios.

Em resumo, trate cada exceção de acordo com a camada do sistema a qual ela pertence.

Evite sujeiras

E por sujeira eu quero dizer exceções checadas. Por exemplo, você gosta da forma como a API IO de Java trata as exceções? Todas elas são checadas! Muitas vezes eu quero fazer algum teste bem bobo no qual eu preciso ler um arquivo ou um properties e adivinha… sim, preciso de um try-catch pra um erro que não há recuperação.  Lembre-se que o tratamento de exceções por meio de try-catch impossibilita melhoria de performance no seu código pela JVM. Isso é muito importante. Sem contar que deixa seu código sujo e “fedido”. Ou então você precisa de mais uma exceção declarada na assinatura do método, o que quebra o encapsulamento (dando dicas pra o cliente do código o que aquele método faz) e dificulta a flexibilidade da API impondo regras a quem quiser herdar aquele método.  Faça o máximo para sempre lançar exceções não checadas, exceto (como já falado) se existir uma forma de se recuperar do erro e você quiser realmente obrigar o cliente a fazer isso. Um aspecto em que você sai ganhando é que em exceções não checadas você pode simplesmente deixar que elas cheguem a parte mais “alta” da aplicação e tratá-las de forma centralizada. Por exemplo, num ambiente web com filtros.  Senão utilizando algum framework de AOP.

Os erros são amigos

É de partir o coração ver algumas pessoas fazerem o seguinte ao tratar erros:


catch(Exception e) {}

ou


catch(Exception e) {

throw new Exception("Erro!");

}

Esses dois exemplos mostram código terrível e jamais devem ser usados. No primeiro o programador simplesmente ignora o erro e este se perde no limbo. Se você for forçado a tratar o erro no seu código, você deve tentar ao menos logar a exceção. Jamais ignore-a completamente como no primeiro caso.  Uma boa abordagem é tentar relançar a exceção em forma de RuntimeException, dando um throw new RuntimeException(e) – ou qualquer outra exceção do tipo RuntimeException que se adeque semanticamente ao erro. Dessa forma, você pára de impor que as camadas acima tenham de tratar ou declarar a exceção. Repito, jamais ignore exceções no catch.

O segundo exemplo é melhor que o primeiro mas ainda assim não é o ideal. Se um outro desenvolvedor está testando sua aplicação e se depara com uma mensagem de exceção dessa? Tipo… o que aconteceu que deu erro? Pois é, você pode ser mais específico e criar uma exceção mais específica para o erro, assim também como uma mensagem mais explicativa. Lembre sempre disso: “Programe sempre como se o cara que fosse  manter seu código fosse um psicopata violento que sabe onde você mora”.

Conclusão

Mostrei aqui algumas dicas de boas práticas sobre como lidar com exceções. Não é nada muito difícil, realmente. Apenas exige esforço constante do desenvolvedor para que o código seja facilmente compreendido. Pense sempre se deve realmente usar uma exceção checada. Na maioria dos casos uma exceção não checada dá conta do recado de forma mais sucinta. Não misture as abstrações das exceções. Exceções de baixo nível em baixo nível, as de alto nível em alto nível. E sempre que for tratar uma exceção, verifique se está tratando no nível correto de abstração. Se estiver, utilize mensagens explicativas sobre o erro ocorrido. E caso encontre aberrações (como a mencionada no começo do post), não se jogue da varanda. Respire fundo e comece a aplicar o que aprendeu.

Padrão

7 comentários sobre “Exceções: “checked ou unchecked – Eis a questão!”

    • Oi Zaca! Verdade que o conceito de checked só existe no Java (que eu saiba). Mas isso não indica que é necessariamente um ponto fraco da linguagem. Existem vantagens em se usar checked exceptions, como eu cito no post. Unchecked devem ser preferidas em frente as checkeds, mas eu realmente vejo grande utilidade nas últimas. Não as descarto de forma alguma.
      O problema são [como sempre] algumas APIs (JDBC é o exemplo clássico) que fazem mal uso delas, obrigando você a fazer coisas absurdas como criar camadas pra tornar checkeds em uncheckeds. Mas é um mal uso por parte do programador e não da linguagem, concorda?

  1. Tiago,

    Legal o post e eu jah vi tambem desses antipadroes de tratamento de excecao em codigo mto critico, graças a Deus eu trabalhava num predio (sem dar nomes Burgos) de um andar soh e um pulo no maximo quebraria um braço.
    Mas me tira uma duvida: foi proposital o o exc.getCause no exemplo do ObjectAlreadyInTransactionException ? Tem algum motivo que eu nao consegui enxergar pra descartar a ConcurrentSerialization e pegar a anterior a ela?
    Falando em “relaxar” as exceçoes e dando preferencia a unchecked quem deu um otimo exemplo foi o Hibernate quando passou de majoritariamente Checked na versao 2 para majoritariamente unchecked na 3, deixou o codigo realmente bem mais legivel!

    R

    • Muito obrigado Rafael! Na verdade você tem razão no meu erro aqui. Não foi proposital não. Acontece depois que você escreve e apaga o exemplo um monte de vezes tentando encontrar o mais apropriado. =] Vlw a dica!
      O hibernate deixou um exemplo a seguir. O Spring desde a primeira versão ignora completamente a existência de checked exceptions. Inclusive o Rod Johnson um dia desses falou que talvez mudasse isso se tivesse que fazer tudo do início. O que me faz pensar ainda mais fortemente que, apesar de devermos dar preferência a unchecked, as checkeds ainda têm seu lugar no atribulado mundo das exceções.

  2. Ruby e outras linguagens dinâmicas não terem checked exceptions faz todo sentido, claro. Como usar um recurso que é focado em “compile time” em linguagens que são focadas no runtime?

    Ter camadas de tradução de checked para unchecked ou de exceptions de baixo nível para exceptions de dominio especifico é ruim apenas se essas camadas só fizerem isso. Para mim é um indicio de que a camada abaixo tem problemas (que podem ser de API, como é o caso de JDBC e RMI). Mas como lidar com o problema? Deixo as [Remote|SQL]Exception subirem? Crio camadas de tradução (inúteis) apenas?

    Bom post.

  3. Zacarias Silva disse:

    Mesmo linguagens estaticas que vieram depois do java nao usam checkedexceptions.

    Hejlsberg, o designer do delphi e .NET fala porque nao usou acheckedexception. http://www.artima.com/intv/anders.html

    Sobre as [REMOTE|SQL] Exception. Quem pegar, traduz. Se ninguem pegar, deixa subir. Camada so pra isso e super organizacao.

    Outros posts sobre checkedexceptions:http://googletesting.blogspot.com/2009/09/checked-exceptions-i-love-you-but-you.html

    Este e sensacional: Checked as nochecked?
    http://www.oreillynet.com/onjava/blog/2004/09/avoiding_checked_exceptions.html

  4. heringer disse:

    Outro problema de fazer o último código citado (colei abaixo) é que quebra o stack trace (pelo menos em c#). Ou seja, quem capturar a exceção, só vai ver o stack trace até esse ponto, não vai ver o stack trace completo.

    catch(Exception e) {
    throw new Exception(“Erro!”); //stack trace quebrado
    }

    catch(Exception e) {
    throw e; //assim também quebra stack trace em C#
    }

    catch(Exception e) {
    throw; //assim não quebra, mas é inútil
    }

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s