try / catch Tratamento de erros e estreitamento no catch

Última atualização: 2026-10-22

try / catch Tratamento de erros e estreitamento no catch

O tratamento de erros no TypeScript tem dois pontos críticos: a variável err do catch é unknown no modo estrito (o JS pode lançar qualquer valor, então o compilador não ousa assumir Error) e precisa ser estreitada antes de usar .message; e "isto pode lançar erro" é invisível nas assinaturas de tipo. As soluções: estreite unknown com instanceof e, para falhas esperadas, use o padrão Result, codificando sucesso/falha direto no tipo de retorno.

GrupoConfiguração e Prática
TipoSintaxe
Modo strictNão necessário

ℹ️ Info O editor transpila TypeScript para JavaScript e o executa (sem verificação de tipos); veja a Saída de cada exemplo para o resultado da verificação.

📝 Sintaxe

// 1) estreitamento de unknown
try {
  risky();
} catch (err: unknown) {
  if (err instanceof Error) console.log(err.message);
  else console.log("unknown throw:", err);
}

// 2) padrão Result: um tipo união que expressa sucesso ou falha
type Result<T> = { ok: true; value: T } | { ok: false; error: string };

function attempt<T>(fn: () => T): Result<T> {
  try { return { ok: true, value: fn() }; }
  catch { return { ok: false, error: "failed" }; }
}

⚙️ Parâmetros

unknownO tipo da variável de catch (o padrão no modo estrito): pode conter qualquer coisa, mas precisa ser estreitado antes do uso — daí vem a segurança
instanceofA ferramenta de estreitamento mais comum: após err instanceof Error você obtém .message/.stack; funciona também com classes de erro personalizadas
Result<T>Um tipo de retorno feito à mão: { ok: true; value: T } | { ok: false; error }. Quem chama precisa verificar ok primeiro; cada ramo expõe apenas value ou error

Retorno:O tipo de retorno do padrão Result é uma união discriminada: value existe apenas quando ok é true, error apenas quando false — a possível falha é codificada no tipo, e quem chama não consegue compilar sem tratar o ramo de falha.

▶ Exemplo

Edite o código abaixo e clique em Testar para ver o resultado transpilado:

Saída:

caught RangeError: not a positive integer: abc
7 0
{"ok":true,"value":42}
failed: invalid input

(Saída de execução após a transpilação; .message só é acessível após o estreitamento por instanceof — tocar em err.message sem isso produz error TS18046)

💡 Observações

ℹ️ Info O JS permite lançar qualquer valor (números, strings, objetos), então o TS tipa a variável de catch como unknown em vez de Error — uma proteção de useUnknownInCatchVariables (incluído em strict) que evita contar com uma propriedade .message que talvez não exista.
💡 Dica instanceof não é a única ferramenta: typeof err === "string", "message" in err e type guards personalizados como isApiError(err) funcionam; mantenha um ramo final de reserva para cobrir qualquer valor lançado.
⚠️ Atenção O padrão Result deixa o código de chamada mais longo (cada chamada precisa verificar ok). Um meio-termo comum: manter exceções no fluxo central e converter para Result nas fronteiras (parsing de entrada do usuário, APIs externas), deixando as falhas esperadas para tratamento explícito.
Mais casos em breve.

📚 Tutoriais relacionados

❓ Perguntas frequentes

P Por que não posso usar err.message diretamente no catch?
R Porque err é unknown (o JS pode lançar qualquer coisa, inclusive strings), então o compilador não pode garantir que .message exista. Estreite primeiro — err instanceof Error, typeof err === "string" ou "message" in err — e então acesse com segurança.
P Como estreitar classes de erro personalizadas?
R Defina a sua própria classe estendendo Error (por exemplo, ValidationError) e estreite no catch com err instanceof ValidationError para alcançar campos personalizados como err.field. Use vários ramos de estreitamento em um mesmo try, ordenados do específico ao geral.
P Quando lançar exceção e quando retornar um Result?
R Exceções servem a situações inesperadas (bugs, queda súbita de rede) que quem chama em geral não deveria tratar; Results servem a falhas esperadas (parsing de entrada, validação de formulários) que quem chama precisa tratar — o tipo o obriga. O teste: quem chama tem um próximo passo significativo após essa falha?
Web-Tutorial.com

Equipe Técnica Web-Tutorial

Uma plataforma de tutoriais mantida por diversos desenvolvedores. Cada tutorial é escrito e revisado por profissionais da área correspondente. Trabalhamos para manter nosso conteúdo preciso e confiável — se encontrar algum problema, avise-nos.

100%