Tratamento de erro que não é só um try/catch genérico vazio

O problema

Tem muito código que “trata erro” assim:

try {
  processa()
} catch (error) {
  console.log(error)
}

Parece seguro.

Não é.

Na prática, esse tipo de bloco frequentemente:

• engole contexto
• esconde falha real
• deixa o fluxo seguir quebrado
• dificulta debug depois

Ou seja, o erro não desapareceu. Só ficou pior de entender.

Modelo mental

Pense assim:

tratar erro não é silenciar exceção; é dar destino correto para a falha

Esse destino pode ser diferente conforme o caso:

• registrar
• propagar
• traduzir
• abortar
• tentar de novo

O ponto é tomar essa decisão com critério. Não por reflexo.

Quebrando o problema

Primeiro entenda que tipo de erro é esse

Algumas perguntas ajudam:

• é erro de negócio ou erro técnico?
• é erro esperado ou anomalia?
• é temporário ou permanente?
• dá para o usuário agir sobre isso?

Sem essa separação, todo erro vira a mesma massa amorfa.

Depois decida o que fazer com ele

As opções mais comuns são:

• registrar com contexto
• devolver resposta clara
• interromper o fluxo
• propagar para camada superior
• aplicar retry com critério

O erro aqui costuma ser usar a mesma resposta para tudo.

Preserve contexto

Se você captura erro e devolve outra coisa sem manter o contexto, o debug fica caro.

Trocar:

payment_provider_timeout request_id=...

por:

something went wrong

é uma forma muito eficiente de odiar a própria madrugada depois.

Não transforme catch em esconderijo

catch só porque “vai que dá erro” é um padrão fraco.

Se a camada atual não sabe resolver a falha, muitas vezes ela deveria:

• adicionar contexto
• e repassar

Não fingir que resolveu.

Exemplo simples

Imagine uma chamada para um gateway de pagamento.

Tratamento ruim:

• captura qualquer erro
• loga string genérica
• retorna false

Agora quem chama não sabe:

• foi timeout?
• foi cartão recusado?
• foi credencial inválida?
• vale retry?

Tratamento melhor:

1. distinguir erro de negócio de erro técnico
2. registrar contexto útil
3. devolver para a camada de cima uma informação que permita reagir direito

Exemplo:

• cartao recusado: resposta de negócio, sem retry
• timeout do provedor: erro técnico, talvez retry ou mensagem de indisponibilidade
• credencial inválida: incidente de configuração, precisa alerta operacional

O código continua simples. Mas a capacidade de operar melhora muito.

Erros comuns

• Usar catch genérico e seguir o fluxo como se nada tivesse acontecido.
• Perder stack trace ou erro original ao traduzir exceção.
• Dar retry em erro que nunca vai melhorar sozinho.
• Mostrar detalhe interno demais para usuário final.
• Misturar erro esperado de negócio com falha técnica grave.

Como um senior pensa

Quem tem mais experiência pensa no caminho inteiro da falha.

O raciocínio costuma ser:

“Se isso der errado, quem precisa saber? O que pode ser feito nesta camada? Que contexto eu preciso preservar para a próxima pessoa ou para a próxima camada entender o que aconteceu?”

Esse pensamento evita dois extremos ruins:

• explodir tudo sem critério
• engolir tudo sem critério

O que o entrevistador quer ver

Em entrevista, esse tema mede julgamento técnico.

O avaliador quer ver se você:

• diferencia tipo de erro
• preserva contexto
• sabe quando propagar
• não usa try/catch como maquiagem de robustez

Uma resposta forte costuma soar assim:

“Eu tentaria separar erro esperado de negócio de falha técnica. A camada que captura o erro precisa ou resolver de fato, ou adicionar contexto e propagar. O que eu evitaria é um catch genérico que esconde a causa e deixa o resto do sistema sem saber reagir.”

Tratamento de erro bom não faz o problema sumir. Faz o problema ficar mais governável.

Catch vazio é o jeito mais rápido de trocar um erro claro por uma investigação ruim.