Blog Felipe Firmo

logofirmo.png
Generic selectors
Exact matches only
Search in title
Search in content
Post Type Selectors
post

Estratégia de Tratamento de Erros

Tratamento de erros é sempre um ponto negligenciado por muitos desenvolvedores. Quem nunca se deparou com um bloco catch vazio? Neste post vou iniciar uma abordagem deste assunto com ênfase na camada SOA.

Ilustração da implementação do Exception Shielding
Detalhes da exceção, em vermelho, sendo filtrados na implementação do serviço

Abordagens

Vou apresentar duas abordagens com seus prós e contras. Esta análise é importante pois é comum vermos decisões de arquitetura sendo tomadas ou defendidas sem embasamento, também conhecido como metodologia ‘goela abaixo’. Por isso costumo apresentar dois caminhos sempre que possível, assim o cliente pode verificar o que melhor se adapta à sua realidade.

Neste caso, a alternativa apresentada seria utilizar ou não o SOA Pattern Exception Shielding

1. Com o uso de Exception Shielding

Este pattern consiste em filtrar detalhes da exceção a fim de evitar que eles comprometam a segurança do ambiente.

approved-151676_640

O ponto positivo deste pattern é não expor detalhes de implementação para o consumidor. Quem não lembra os famosos erros não tratados que expunham usuário e senha do banco de dados na interface web?

remove-151678_640

O ponto de atenção é que sua implementação pode prejudicar a identificação e solução de erros devido a falta de informação sobre os mesmos enviadas ao consumidor.

atenção

Para contornar este ponto, o sistema onde o erro foi originado deve logar o erro completo juntamente com uma chave única, que será retornada ao consumidor. Desta forma, quando um erro se manifesta o usuário pode encaminhar esta chave única do erro para a equipe de sustentação, facilitando assim a identificação do mesmo.

2. Sem o uso de Exception Shielding

Esta segunda estratégia é mais simples e mais frequentemente utilizada. Nela todos os detalhes do erro, como stack trace, são compostos na mensagem e retornados ao(s) consumidor(es). Este(s), por sua vez, deve(m) garantir que tais detalhes não sejam exibidos ao usuário final.

approved-151676_640

Implementação mais simples;
Fácil troubleshooting;

remove-151678_640

Exposição de detalhes de implementação dos provedores aos consumidores, muitas vezes parceiros ou externos.

atenção

Mesmo mais simples, muitas vezes nem este nível de tratamento de erros é implementado em grande parte dos casos. É comum encontrar sistemas que enviam mensagens genéricas aos consumidores e a única forma de troubleshooting é com acesso a log da aplicação, o que muitas vezes não está acessível a equipe.

Conclusão

O uso deste pattern deixa a solução mais bem acabada, porém requer uma maior maturidade e estrutura para disponibilizar uma forma adequada de troubleshooting. Então é natural iniciar de forma mais simples, mas acredito ser importante caminhar para a padronização do tratamento de erros, tanto em termos de mensagem ao usuário final (que não foi abordado neste post) quanto com relação a geração e consulta dessa chave única para o troubleshooting.

É importante ressaltar que independente da abordagem utilizada é importante ter uma estrutura padronizada para retornar estes dados. Caso seja SOAP seria através de um elemento no detail do SOAP Fault. Caso seja REST, utilizar o HTTP Status Code correto e retornar uma estrutura JSON padronizada com mais detalhes.

Já conhecia estas estratégias? O que utiliza na sua empresa? Vamos continuar o assunto nos comentários 😉

2 Comments

  1. Diego Neri

    Felipe, bem didática e objetiva sua explicação sobre o assunto, parabéns.
    Você acredita que esta decisão pode ser deixada para um segundo momento, ou seja, implemento num primeiro momento e então, busco a melhor prática?

    Ainda falando do pattern, concordo com a primeira abordagem, desde que haja uma boa estrutura e que seja uma referencia estressada ao máximo.

    1. Felipe Firmo

      Obrigado Diego!

      Você acredita que esta decisão pode ser deixada para um segundo momento, ou seja, implemento num primeiro momento e então, busco a melhor prática?

      Você mesmo deu a resposta 😉

      Mas ao ler seu comentário percebi que algo importante não ficou claro no conteúdo do post:

      Considero o uso do pattern obrigatório em caso de exposição de serviços a parceiros e exposição de ‘API’ públicas.

      Respondendo sua pergunta, o ótimo é inimigo do bom! Então a não ser que se enquadre no cenário acima (Parceiro/API) muitas vezes é mais viável iniciar com um modelo padronizado de tratamento de erros, para depois partir para o Exception Shielding. Mas é importante implementar a segunda abordagem corretamente, isso não deveria ser tão desafiador/custoso.

Deixe um comentário

O seu endereço de email não será publicado. Campos obrigatórios marcados com *