Tradução da página original em inglês. Em caso de divergência, vale a versão em inglês.
Erros e problem+json
Os erros são cidadãos de primeira classe no DaloyJS. Todo HttpError lançado é serializado como problem+json RFC 9457, com uma URI type estável, um request id e o Content-Type adequado.
- 01handlerthrow new NotFoundError(...)qualquer subclasse de HttpError
- 02frameworkMapear para os campos RFC 9457type · title · status · detail
- 03produçãoOcultar o detail de 5xxexibido só quando o ambiente é development ou test
- 04redeResposta serializadaapplication/problem+json + x-request-id
Classes de erro embutidas
TooManyRequestsError e ServiceUnavailableError validam retryAfterSeconds da mesma forma: qualquer coisa que não seja um inteiro seguro não negativo lança um RangeError na construção, então um NaN vindo de uma variável de ambiente ausente nunca vira um cabeçalho Retry-After inválido. RequestTimeoutError (o prazo de requestTimeoutMs, veja requestTimeoutStatus, em inglês) é no-store em todas as variantes de status desde a 1.16.0, então um cache compartilhado nunca continua servindo um 503/504 depois que o backend se recupera. Um new HttpError(status, …) puro recebe um type de problema https://httpstatuses.io/<status>; as classes embutidas trazem URIs estáveis https://daloyjs.dev/errors/<slug>.
Lançando erros em um handler
Formato na rede
O request id é devolvido ao cliente em dois lugares: no cabeçalho de resposta x-request-id e (conforme a RFC 9457 §3.1) no campo instance do documento de problema, como uma URN urn:request:<uuid>. Não existe uma propriedade requestId no nível superior: os clientes devem ler o cabeçalho ou extrair a URN de instance.
Ocultação em produção
O DaloyJS remove o campo detail de qualquer resposta 5xx, a menos que o ambiente seja comprovadamente development ou test, para que mensagens de erro internas e trechos de SQL não vazem para os clientes. O erro completo continua sendo enviado ao seu logger e ao hook onError.
| Configuração | detail de 5xx |
|---|---|
env: "development" ou env: "test" | exibido |
sem env, NODE_ENV=development ou test | exibido |
sem env, NODE_ENV não definido, vazio ou qualquer outro valor | ocultado |
env: "production", production: true ou NODE_ENV=production | ocultado |
production: false com NODE_ENV não definido | ocultado |
Um ambiente não definido falha de forma fechada de propósito. Runtimes de edge como Cloudflare Workers e Deno Deploy não têm NODE_ENV, e tratar isso como desenvolvimento enviaria mensagens de exceção aos clientes. O daloy dev define NODE_ENV=development no processo filho quando você não o definiu, então o desenvolvimento local continua exibindo o detalhe. Erros que você mesmo serializa (por exemplo, um corpo de resposta montado a partir de err.message em um bloco catch) não são ocultados. Lance-os em vez disso, ou lance um HttpError com um detail seguro.
Classes de erro personalizadas
Todas as classes embutidas acima definem um type https://daloyjs.dev/errors/<slug>. Um HttpError simples lançado sem type recorre a https://httpstatuses.io/<status>. Os middlewares oficiais que respondem 503 (loadShedding(), concurrencyLimit(), requestTimeoutStatus: 503) definem o próprio type daloyjs.dev, então esse fallback só se aplica aos erros que você mesmo constrói. Defina type quando os clientes dependerem dele, ou use uma classe embutida:
Serviço indisponível
Para modo de manutenção, indisponibilidade de uma dependência ou uma instância sendo drenada, lance ServiceUnavailableError. Ele responde 503 com um type estável https://daloyjs.dev/errors/service-unavailable, um Retry-After opcional e cache-control: no-store, para que uma CDN nunca continue servindo a indisponibilidade depois que você se recuperar.
retryAfterSeconds precisa ser um inteiro não negativo. Qualquer outra coisa (NaN vindo de uma variável de ambiente ausente, -1, 1.5) lança um RangeError em vez de enviar um cabeçalho Retry-After malformado.
onError personalizado
Última atualização: