O uso de exceptions no .NET tem sido um tópico de debates acalorados na comunidade. Para alguns, exceptions representam um custo desnecessário, um vestígio de práticas antiquadas que poderiam ser substituídas por abordagens mais eficientes. Para outros, são um pilar essencial para a robustez e previsibilidade do software moderno.
Se exceptions realmente fossem um problema significativo, por que ainda são adotadas de forma unilateral, em todo lugar, principalmente nos componentes centrais do ecossistema .NET, no ASP.NET, no Entity Framework e em diversas bibliotecas e fundações da própria Microsoft?
Será que há questões que não estamos considerando?
Antes de abraçar qualquer lado, é fundamental analisar a questão de forma técnica e pragmática.
Esta série de artigos pretende fornecer respostas, e levantar questionamentos importantes.
Em 2019…
Em 2016~2019 uma onda de “ataque às exceptions” apareceu na comunidade. Posts e mais posts falando mal de exceptions.
Até então, tudo bem, se não fossem os argumentos para trocar exceptions por notificações.
Foi então que resolvi parar para escrever sobre o assunto em um dos posts que mais rendeu aqui no gaGO.io:
Notification Pattern – Estão te vendendo um conceito errado
Notification Pattern prevê uma forma permissiva que troca exceptions por notificações em um determinado contexto, no entanto embora a maioria das publicações a respeito falem em não lançar exceptions, veremos que isso não é bem assim.
De 2021 a 2025 muita coisa aconteceu:
Nesse período, parece que se intensificaram os esforços. Vamos ver alguns vídeos interessantes.
JUL/2021 – Nick Chapsas
O custo oculto das exceções no .NET
JUN/2022 – Nick Chapsas
Não lance exceções em C#. Faça isso em vez disso
ABR/2024 – Nick Chapsas
.NET 9 corrigiu exceções, mas ainda não as use
JUL/2024 – Milan Jovanović
Exceções são extremamente caras… Faça isso em vez disso
JUL/2024 – Gui Ferreira
Adeus Exceções! Olá Padrão de Resultado!
SET/2024 – Dan Patrascu
Quando lançar exceções?
DEZ/2024 – Filip Ekberg
Pare de usar exceções em C#! Aqui está o porquê e o que fazer em vez disso
Fev/2025 – No LinkedIn
No início de Fev/2025, no LinkedIn, abordei a proliferação de try-catchs desnecessários em um projeto que tive acesso, em um processo seletivo.
Durante o debate promovido nos comentários, um comentário me chamou a atenção. Embora ele tenha dito que não era a meu respeito.
Como resultado, passei o final de semana rodando benchmarks
e o resultado foi surpreendente.
Mas não poderia pecar na mesma negligência da qual luto contra. Não poderia incorrer no mesmo erro. Portanto, é preciso contextualizar antes de publicar o resultado desses testes, exatamente porque é tênue a linha que separa o desfazer de uma falácia e a criação de outra em seu lugar.
Quero cuidar da precisão dessas informações para evitar o que considero um dos maiores problemas do nosso mercado: conteúdos rasos, com contextos rasos, sem fundamentos, pautados em achismos e perspectivas não fundamentadas.
Não acaba aqui, nossos próximos passos
Este artigo é apenas o ponto de partida de uma série de investigações. As próximas publicações abordarão um estudo empírico detalhado, com benchmarks rigorosos e simulações práticas. O objetivo será quantificar com precisão se exceptions representam um gargalo de desempenho significativo ou se sua suposta ineficiência é um mito amplificado por análises superficiais.
Além disso, exploraremos:
- Casos de uso onde exceptions podem ser substituídas por abordagens alternativas sem perda de robustez;
- A relação entre exceptions e arquitetura de software, analisando impactos além da performance bruta;
- Como boas práticas podem mitigar possíveis desvantagens no uso de exceptions.
A complexidade desse tema exige uma abordagem meticulosa, baseada em evidências concretas e análises aprofundadas. Estamos apenas começando a desvendar essa questão.
Se há algo que ainda não sabemos, precisamos descobrir.
E é exatamente isso que faremos nos próximos capítulos desta série.
Excelente!!!
Além do custo da exception, vejo que usar da forma correta ajuda até a entender o comportamento do sistema.
Exemplo o saldo insuficiente.
Por trás pode estar encondendo um erro de conexão com o banco que impediu de retornar o saldo.
Como também pode estar escondendo um erro de negócio.
– O front pode estar permitindo o cliente realizar tentativa de transação sem validar o saldo, e bastaria apenas gerar uma Notification.
Essa separação me ajudou a categorizar e logar corretamente eventos inesperados que interrompe o fluxo, e o dashboard da aplicação ter segregação entre Informação, Error e Warning.
É erro gerado por falha, indisponibilidade, …?
– Vai cair no global exception.
– Level Log = Error, dependendo pode ter auxílio do time de infra.
É Notification?
– Level Log = Warning, vai ser aberto uma Task para entender o motivo.
– Dependendo pode envolver área de negócios para correção de fluxo ou validação.