Gerar ou não uma exception é um assunto bastante recorrente e muitas vezes gera muita polemica. Eu mesmo escrevi sobre este tema (links ao final).
Vamos tentar agora abordar este tema sobre outro viés : Escolher lançar ou não uma exception baseado no conceito de responsabilidade e Escopo:
- ➡ Se for sua a responsabilidade (escopo da função/método) evite ao máximo lançar exception.
- ➡ Se NÃO for sua responsabilidade não precisa inventar e/ou usar nenhum patterns apenas lance uma exception
Simples né…vamos explorar estes conceitos:
👉 Função/método públicos (Com baixo acoplamento): Parâmetros e contratos devem ser validados uma vez que a origem dos dados pode não ser confiável. Isso é sua responsabilidade logo tente evitar as exception.
👉 Função/método públicos (Com Alto acoplamento): Igual ao primeiro , porém no mundo real nem sempre temos implementações corretas e estes contextos têm acoplamento com variáveis e classes internas. Estas variáveis e classes devem ser validadas, mas caso falhem fique à vontade para gerar uma exception. Seu contexto não é responsável por elas, isso é um débito técnico que a falha deve ser corrigida na sua origem e não no seu contexto. Embora seja uma ação mais radical garante que sua aplicação tenha consistência dentro do contexto evitando cenários que deveriam ser tratados antecipadamente, e mais importante não propaga esta inconsistência para demais chamadas subsequentes.
👉 Bibliotecas de uso Específico : Cada biblioteca tem sua complexidade e características mas segue o mesmo princípio dos escopos púbicos.
👉 Bibliotecas de uso Geral (Helpers) : Aqui é uma opinião mais pessoal… Faz um bom tempo que tento evitar este tipo de biblioteca pois ela na maioria dos casos não foi projetada para ter um baixo acoplamento, mas se for o seu caso nem deveria ter validação é se tiver fique à vontade para gerar uma exception, o conceito dela é apoiar/simplificar um contexto maior e este sim deve garantir os parâmetros corretos. Como evitar seu uso ? em .NET Utilizando o conceito de extensions (.NET) ou local functions.
👉 Função/método privados/internos : Escopos internos não deveriam ter validações, e caso existam fique à vontade para gerar uma exception pois a origem do problema está na falta de validação de uma camada superior.
Estas abordagens não devem ser encaradas como “arauto da verdade” nem uma regra a ser aplicada em qualquer contexto, pense isso como um guia para ajudar e evitar debates que muitas vezes sua origem vem da falta de um planejamento mais estratégico da construção da sua aplicação voltada para uma gestão de erro mais efetiva.
Tenham um excelente dia! Eu sou Fernando Cerqueira e entrego estratégias digitais para os desafios do presente, com propostas de inovação para um futuro sustentável.
