{
}
FALE COM A HAUSTI
Conecte-se com a hausti //
Hausti | Tecnologia Inteligente
Hausti | Tecnologia Inteligente
{
}
FALE COM A HAUSTI
hausti | tecnologia inteligente
Em 30 de março por Rafael Peres
VOLTAR

Exception vs. Result Pattern: pare de usar o try-catch como muleta de fluxo

Exception vs. Result Pattern: pare de usar o try-catch como muleta de fluxo

Se você abre um código e encontra blocos de try-catch espalhados por todas as camadas para tratar regras de negócio, você não está diante de um sistema resiliente. Você está diante de uma arquitetura baseada em “torcer para que funcione”.

No desenvolvimento moderno de alta performance, exceções devem ser o que o nome diz: excepcionais. Erros de validação, falta de saldo ou usuário não encontrado não são exceções catastróficas; são resultados previstos do domínio.

Na Hausti, defendemos o Result Pattern para substituir o fluxo de exceções por um design determinístico e elegante.

O custo invisível das Exceções

Lançar uma Exception no .NET ou em qualquer stack moderna é caro. O runtime precisa capturar o stack trace, desenrolar a pilha de chamadas e gerenciar o estado da thread. Se você usa isso para validar um CPF, você está queimando CPU à toa.

Além disso, o try-catch quebra a assinatura dos seus métodos. Olhando para um método public User CreateUser(...), você não sabe se ele pode explodir. Com o Result Pattern, o contrato é explícito.

O que é o Result Pattern?

Em vez de um método retornar apenas o objeto (ou lançar um erro), ele retorna um objeto de Resultado. Esse objeto diz duas coisas:

  1. A operação teve sucesso? (Booleano)
  2. Se falhou, qual foi o erro? (Lista de erros ou Notificações)
  3. Se funcionou, qual o valor de retorno?

Exemplo Prático (O jeito “Dev de Prompt”):

// Errado: Usando exceção para regra de negócio
public void Sacar(decimal valor) {
    if (valor > _saldo) 
        throw new Exception("Saldo insuficiente"); // ISSO NÃO É UMA EXCEÇÃO!
    _saldo -= valor;
}

O Jeito Hausti (Result Pattern):

// Correto: O retorno expressa a intenção e o resultado
public Result Sacar(decimal valor) {
    if (valor > _saldo) 
        return Result.Failure("Saldo insuficiente.");
    
    _saldo -= valor;
    return Result.Success();
}

Vantagens de “desenvolver de verdade”

  1. Assinaturas Previsíveis: Quem consome o método sabe exatamente o que tratar. Não há surpresas em tempo de execução.
  2. Performance: Zero custo de geração de stack trace para erros comuns de validação.
  3. Clean Code: O código fica muito mais legível. Você elimina o “ninho” de catches e trabalha com verificações simples de result.IsSuccess.
  4. Fail-Fast: Você valida tudo antes de tentar qualquer operação pesada, garantindo a integridade dos dados.

Quando a Exceção ainda é válida?

Não estou dizendo para deletar o try-catch do seu dicionário. Ele continua sendo vital para o que é imprevisto:

  • O banco de dados caiu.
  • O disco lotou.
  • A rede falhou.
  • Um timeout inesperado em uma API externa.

Para tudo o que faz parte da regra de negócio (validações, permissões, estados de objeto), o Result Pattern é o padrão ouro.

Conclusão

Desenvolver software de alta escala exige que o desenvolvedor tome as rédeas do fluxo da aplicação. Delegar a lógica de negócio para o mecanismo de exceções do sistema operacional é abrir mão da performance e da manutenibilidade.

Na Hausti, implementamos padrões de arquitetura que garantem que o sistema se comporte exatamente como esperado, com validações reais e tipadas. Menos “torcida”, mais engenharia.

Sua arquitetura está preparada para escalar ou ela vive “caçando” exceções?
A Hausti está pronta para elevar o nível do seu projeto.

Haust'n'joy/
Fechar