Sem sombra de dúvidas, o principal argumento que sustenta a ideia de que exceptions são ruins é o custo. Afinal, ninguém quer colar em si uma placa dizendo que “optou pelo caminho mais lento“.

Ao mesmo tempo, as discussões acaloradas transformam o debate em uma rinha onde cada qual adota uma postura que desqualifica toda e qualquer opinião contrária.

Mas afinal, quanto custa uma exception?

Este artigo não pretende fornecer respostas definitivas, mas levantar questionamentos importantes:

Será que estamos ignorando alguma peça fundamental nessa discussão? A aversão às exceptions é justificada por dados concretos ou apenas uma tendência emergente sem embasamento empírico suficiente?

Uma análise superficial pode enganar?

O principal argumento contra exceptions está no seu suposto alto custo computacional. De fato, quando uma exceção é lançada, o runtime do .NET precisa capturar o estado da pilha, criar um objeto de exceção e executar o processo de unwinding da stack até encontrar um manipulador adequado. Sem dúvida, esse overhead é significativamente maior do que o de um simples if/else.

Mas a pergunta fundamental que não estamos fazendo é:

Que custo é esse? Esse custo realmente importa? Ele é relevante dentro do contexto de aplicações modernas que precisam acessar banco de dados relacional, nosql, cache, consumir mensagens de uma infra de mensageria ou stream, ou chamar apis http/rest, ou enviar logs pela rede opentelemetry?

Benchmarks: Comparação com outras operações

Ao analisar benchmarks, observamos que lançar uma exceção é muitas vezes mais custoso do que adotar if’s. Esses comparativos estão na casa dos nanosegundos (ns) ou microssegundos (μs).

No entanto, quando comparado a operações triviais em sistemas modernos, esse impacto pode ser marginal:

• Consultas a bancos de dados (~2-5ms);
• Acessos a cache distribuído como Redis (~0.5-1ms);
• Chamadas a APIs REST (~5-50ms, dependendo da rede e latência);
• Processamento de mensagens assíncronas em filas distribuídas (~2-5ms, dependendo da carga do sistema).

Em todos os exemplos acima, optei por valores utópicos. No mundo real, dá para multiplicar esses números algumas vezes.

Dado esse cenário, será que o custo das exceptions realmente justifica evitá-las completamente?

• A Microsoft, ao projetar o novo e moderno ASP.NET Core e o próprio .NET Runtime, não as removeu. Será que deveríamos?
• Qual é o impacto real na execução das aplicações?

Talvez uma informação adicional possa nos ajudar a refletir sobre:

Valor	Em Segundos	Em Milisegundos
1 ns : 1 Nanosegundo	0,000 000 001 seg	0,000 001 ms
1 μs : 1 Microsegundo	0,000 001 seg	0,001 ms

Em vez de analisar exceptions apenas sob a ótica da performance comparando com o custo de um simples IF, precisamos contextualizar seu uso dentro do fluxo de execução da aplicação, entendendo quando seu custo é relevante e quando não é.

Por exemplo, no vídeo do JUL/2021 – Nick Chapsas – O custo oculto das exceções no .NET que referenciei no post anterior, temos:

• Medição em nanosegundos | 1 ns = 0,000 001 ms

A ausência de latência foi algo que me chamou a atenção em todos os benchmarks. Afinal, qual a relação entre nanosegundo/microssegundo com milissegundos?

Para entender o impacto da latência na expressividade do custo das exceptions resolvi fazer testes adicionando latência. Assim, rodei o benchmark acima por 45h38m, rodando 120 benchmarks diferentes, por todo esse período.

Quando adicionamos 2 milissegundos à execução, temos números mais expressivos, números que fazem mais sentido à compreensão humana.

2 ns = 1 Nanosegundo = 0,000 000 001 seg = 0,000 001 ms

assim

2ms = 2’000’000 ns

Assim, podemos ter uma noção melhor de quanto custa uma exception em relação à execução de uma aplicação, que, por exemplo, acesse um banco de dados.

Trazer os números do teste para a escala dos milissegundos torna o resultado menos abstrato. Agora é quase como se pudéssemos tocá-los.

Ainda vou detalhar esse teste, sua metodologia, em um post dedicado ao assunto, mas por hora é possível entender que a escala faz total diferença.

Será que estamos fazendo as perguntas certas?

A questão das exceptions não pode ser reduzida a um debate simples sobre custo, precisamos separar custo de valor.

Para isso, precisamos fazer perguntas mais profundas:

• O custo computacional das exceptions é realmente significativo?
  Em quais cenários?
• Até que ponto os benchmarks que desconsideram latência são confiáveis?
  Será que eles apresentam uma visão tendenciosa do problema?
• Estamos realmente buscando otimização de milésimos ou centésimos de milissegundo enquanto ignoramos impactos na arquitetura do software?
• Quais são os trade-offs reais entre código mais legível e pequenas otimizações de desempenho?

As críticas às exceptions geralmente nascem do uso inadequado. Como uma faca, que pode ser usada tanto para o bem quanto para o mal, seu mau uso pode gerar problemas reais.

Mas será que a solução seria simplesmente evitá-las?
Ou deveríamos buscar diretrizes mais claras para seu uso eficiente?

Próximos passos

No primeiro post, você viu diversas referências em vídeos que defendem a abolição das exceptions. Neste post, você viu que há uma questão sobre esse argumento central do custo de exceptions, a escala.

A escala em nanossegundos ou microssegundos é injusta, visto que todas as nossas grandes operações acontecem na escala dos milissegundos.

Dizer que lançar exception custa 10 vezes, custa 30 vezes mais, pode ser um argumento verídico, entretanto perde força quando olhamos para a escala dos milissegundos.

Ao trocarmos de escala, a tortura estatística derrete.

Da mesma forma que grandes números são inimagináveis.

Pequenos números também são.

Por isso é tão importante trazer para a escala de milissegundos (ms) em vez de continuar em nanossegundos (ns) ou microssegundos (μs). Mas é preciso muito cuidado para não fazer parecer que não há custo. A questão é sobre qual ponto de referência estamos adotando. Se tomarmos como referência o custo de um if, a exceções são muito mais caras, mas se tomarmos como referência um request http, uma operação maior, esse custo quase desaparece, se torna imperceptível. Só reaparecendo diante de um cenário de múltiplas exceções sendo lançadas na mesma execução, mas aqui o problema não é a exception, mas o tratamento equivocado.

Para essa discussão evoluir, preciso realmente fazer considerações:

• Para que lançamos exceptions
• Quando lançamos exceptions
• Onde lançamos exceptions, onde não lançamos.
• Por que tratamos?
• Onde não devemos tratar, devemos deixar estourar.
• Como tratamos.
• Onde tratamos.
• O que é tratar, e o que fazer em cada contexto.

e todos os detalhes para assegurar que, ao apresentar o resultado do benchmark, não alimente a ideia de uso indiscriminado e ilimitado de exceptions.

Por isso, o próximo post falará sobre as boas práticas com exceptions.