Skip to main content
Todo erro que a API devolve como resposta HTTP é lançado como RoutaApiError ou uma de suas subclasses. Todas carregam:

Classes de erro

Uma subclasse também é um RoutaApiError. Teste as subclasses mais específicas primeiro, como no exemplo acima.

Tratando casos de negócio

Use o code para decidir o que fazer, não o texto da mensagem.
Um 402 chega como RoutaApiError, não como uma subclasse. Trate message_quota_exceeded por code e não programe retentativas automáticas: esperar não aumenta a franquia. Veja Planos e franquia.

O que o SDK já retenta

Falhas de rede, 429, 5xx e um 409 idempotency_in_progress são retentados automaticamente, até maxRetries vezes. Só o erro final chega ao seu catch. 401, 403, 404 e 422 nunca são retentados. Veja Configuração.

O que não é um RoutaApiError

Duas situações não passam por essas classes:
  • Falhas de rede e timeouts, depois que as retentativas acabam, rejeitam com um Error simples cujo name é 'HttpRequestError'. A classe ainda não é exportada, então verifique error.name em vez de usar instanceof.
  • Configuração inválida, como uma apiKey vazia, lança um Error simples e síncrono no construtor Routa.
Uma falha de validação de schema (por exemplo, um campo obrigatório ausente) chega como RoutaInvalidRequestError com o código unknown_error, porque a resposta não vem no formato de erro da Routa. Veja Erros de validação de schema.

Falhas de entrega

Uma falha do provedor não vira exceção em messages.send(): a mensagem é aceita e a falha aparece depois, de forma assíncrona, como o evento message.failed. A classe RoutaProviderError existe para um uso futuro e nenhum código do SDK a lança hoje.