Referência de Classe de Erro do SDK TypeScript

Porque no SDK TypeScript, APIConnectionError é uma subclasse de APIError, não uma classe irmã. Uma verificação instanceof Anthropic.APIError também corresponde a erros de conexão, portanto, se essa verificação vier primeiro em uma cadeia if/else if, o ramo mais específico APIConnectionError nunca será executado.

Não. No SDK Python, APIConnectionError é uma classe irmã de APIError, não uma subclasse. Código portado do Python para TypeScript que assume a mesma relação pulará silenciosamente o ramo de erro de conexão.

Geralmente não. O SDK já retenta automaticamente erros 429, 5xx e de conexão com backoff exponencial, usando um maxRetries padrão de 2. Adicione sua própria lógica de retentativa apenas se precisar de uma contagem de retentativas diferente, estratégia de backoff ou comportamento de enfileiramento.

BadRequestError (400), AuthenticationError (401), PermissionDeniedError (403), NotFoundError (404) e UnprocessableEntityError (422). Retentar esses erros desperdiça uma requisição, pois o payload ou as credenciais, e não a rede ou a carga do servidor, causaram a falha.

Qualquer erro de SDK tipado que não correspondeu a uma verificação instanceof mais específica anteriormente na cadeia, pois cada classe de erro específica estende APIError. Coloque-a por último em uma cadeia catch como uma rede de segurança, não como seu caminho de tratamento principal.

.status é o código de status HTTP (um número, como 429). .type é a própria string de tipo de erro da API (como "rate_limit_error" ou "overloaded_error"), que permite distinguir causas que compartilham o mesmo código de status.

Sim, overloaded_error pode chegar sob um status 429 ou 5xx dependendo da causa, que é exatamente o caso em que verificar .type além da classe mapeada por status fornece informações mais precisas.

Qualquer coisa que impeça uma resposta de chegar, como uma falha de DNS, uma conexão interrompida ou um tempo limite do lado do cliente. É distinto dos erros de código de status porque nenhuma resposta HTTP foi recebida.

Para um aplicativo pequeno, uma função wrapper compartilhada (como askClaude acima) que centraliza a cadeia catch mantém o tratamento consistente. Para aplicativos maiores, envolva a cadeia catch em uma utilidade para que cada local de chamada obtenha a mesma classificação de retentável/não retentável sem duplicar a cadeia if/else if.

Sim. O else final no exemplo relança qualquer coisa que não seja um APIError do SDK, como um bug em seu próprio código de chamada. Engolir erros não-SDK silenciosamente torna bugs reais mais difíceis de encontrar.

Menos comum que BadRequestError, pois significa que a requisição era um JSON sintaticamente válido, mas falhou em uma verificação semântica, como um valor que é do tipo correto, mas fora de um intervalo permitido.

O exemplo usa claude-sonnet-5, o modelo padrão na linha atual de modelos Claude (Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5, Claude Haiku 4.5). Substitua pelo modelo que seu aplicativo tem como alvo.