Try-catch acelera o código? Análise do paradoxo e erros em C#

Como o bloco try-catch pode "acelerar" seu código em C#? Analisando mitos e realidade

Imagine a situação: você está escrevendo código em C#, executa-o e, de repente, percebe que ao adicionar o bloco try-catch, o programa começa a funcionar mais rápido. Parece mágica ou, ao contrário, um erro grosseiro de iniciante? Na verdade, esta pergunta reuniu milhares de visualizações no Stack Overflow. E a resposta vai te surpreender: o try-catch por si só não acelera o código, mas pode alterar drasticamente o comportamento do compilador JIT, o que às vezes leva a um ganho inesperado de desempenho. Vamos analisar esse paradoxo e, ao mesmo tempo, os principais erros ao trabalhar com exceções que podem transformar seu código rápido em uma bagunça lenta.

Por que surge a ilusão de aceleração?

A pergunta no Stack Overflow era mais ou menos assim: "Escrevi dois métodos: um com try-catch, outro sem. O método com try-catch funciona mais rápido. Por quê?"

O ponto-chave é o compilador JIT (Just-In-Time). Quando o código C# é compilado para IL e depois para código de máquina, o JIT pode aplicar diferentes otimizações. Se dentro do bloco try não houver lançamento explícito de exceção, o compilador pode desativar algumas otimizações (como inlining de métodos ou reordenação de instruções) para garantir a correta operação da pilha em caso de exceção. Isso parece ruim, mas em alguns cenários raros (especialmente em versões antigas do .NET Framework) o JIT podia se comportar de forma contraintuitiva: o código sem try-catch sofria uma otimização agressiva que quebrava o cache do processador, enquanto o código com try-catch não. Como resultado, a segunda opção funcionava mais rápido.

// Exemplo que pode enganar\npublic int SumWithoutTry(int[] array)\n{\n    int sum = 0;\n    for (int i = 0; i < array.Length; i++) // Sem try-catch\n    {\n        sum += array[i];\n    }\n    return sum;\n}\n\npublic int SumWithTry(int[] array)\n{\n    int sum = 0;\n    try\n    {\n        for (int i = 0; i < array.Length; i++)\n        {\n            sum += array[i];\n        }\n    }\n    catch (Exception) { /* não fazemos nada */ }\n    return sum;\n}\n

Nas versões modernas do .NET (Core 3.0+, .NET 5/6/7/8), esse efeito praticamente desapareceu. O JIT se tornou mais inteligente e o try-catch não afeta a velocidade em loops simples como esses. Mas o simples fato de essa pergunta existir é uma ótima oportunidade para falar sobre como trabalhar corretamente com exceções.

Principais erros ao usar try-catch em C#

Agora que esclarecemos o mito, vamos passar para os problemas reais. Aqui está uma lista dos erros mais comuns que realmente tornam seu código mais lento e menos confiável.

1. Usar exceções para controlar o fluxo

Isso é clássico. Programadores vindos de linguagens com tratamento "preguiçoso" de erros às vezes escrevem assim:

// RUIM\ntry\n{\n    int.Parse(inputString);\n}\ncatch (FormatException)\n{\n    // Se não parseou — usa o valor padrão\n    inputString = "0";\n}\n

O problema é que lançar uma exceção é uma operação muito cara. O JIT precisa construir a pilha de chamadas, criar o objeto de exceção, percorrer os blocos catch. Em vez disso, use TryParse:

// BOM\nif (int.TryParse(inputString, out int result))\n{\n    // trabalha com result\n}\nelse\n{\n    // tratamento de erro sem exceção\n}\n

Conclusão: Nunca use try-catch como substituto para um operador condicional. Exceções são para situações excepcionais, não para lógica comum.

2. Bloco catch vazio

"Engolir" uma exceção é uma das piores práticas: