ReadonlydetailThe caller-facing disclosure, served verbatim — required here, where
ErrorResponseInit leaves it optional, because a hint that
omitted it would fall back to the Error's own message.
It must contain nothing the thrower would not put in an unauthenticated response body.
Optional ReadonlydetailsOptional structured details (e.g. a validation errors array).
ReadonlystatusThe HTTP status to answer with. Must be an integer in 400–599; a
hint outside that range is treated as ABSENT and the error takes the
ordinary masked-500 path, because a hint says how an ERROR should be
answered and a status the platform cannot serve would make the error
handler itself throw.
ReadonlytitleThe framework-default error member. In a formatted response this is the
Problem Details detail when no detail is supplied.
How an error should be answered, as decided by the code that threw it.
It is an
ErrorResponseInit— the same shaperespondWithErrortakes — because it says the same thing: the status, title and disclosure of one error response. Reusing it is what lets@setu-ts/exceptionsbuild the response body through ONE implementation, so a hinted throw and arespondWithErrorcall carrying the same values answer byte-identically under every configured format.detailis required, and that is the point. The brand does not serve theError's ownmessage: a message is written for an operator and may quote a statement, a bound parameter or a driver's own text, which is exactly the disclosuremaskInternalErrorsexists to stop (X12-3). Making the caller-facing sentence an explicit act at the brand site keeps caller-safety a decision rather than an inference, so a hinted response can be exempted from masking without widening what masking protects.Example
Since
0.4.0