Describe the problem
In SvelteKit, it can be difficult to understand where and why a request was handled with an expected error.
In larger codebases, patterns like error(401, 'must authenticate') are often used in many different places across load functions, actions, hooks, and endpoints. When one of these expected errors is returned, there is currently no built-in way to observe it centrally in the same way unexpected errors can be observed through handleError.
This makes local development and debugging harder, because it can be non-trivial to trace which code path produced the expected error and why a request ended up with that result.
Describe the proposed solution
Make expected errors available to handleError as well, and include metadata that distinguishes them from unexpected errors.
For example, handleError could receive all errors with something like an expected: true | false property. That would allow developers to centrally log, inspect, and debug expected errors during development, while still preserving the distinction between expected and unexpected failures.
This would make it much easier to answer questions like:
- where was this error thrown?
- which route/load/action/endpoint produced it?
- why did this request resolve with this expected error?
The main goal is not to change runtime behavior for users, but to give developers a single hook for observability and debugging.
Alternatives considered
A custom wrapper around error(...) could be used to add logging or tracing.
However, in an existing codebase this would likely require a large refactor, especially if the error(...) pattern is already used in many places. A built-in solution through handleError would be much more ergonomic and consistent.
It could also be a dedicated hook.
Importance
would make my life easier
Additional Information
Based on this discussion here
Describe the problem
In SvelteKit, it can be difficult to understand where and why a request was handled with an expected error.
In larger codebases, patterns like
error(401, 'must authenticate')are often used in many different places across load functions, actions, hooks, and endpoints. When one of these expected errors is returned, there is currently no built-in way to observe it centrally in the same way unexpected errors can be observed throughhandleError.This makes local development and debugging harder, because it can be non-trivial to trace which code path produced the expected error and why a request ended up with that result.
Describe the proposed solution
Make expected errors available to
handleErroras well, and include metadata that distinguishes them from unexpected errors.For example,
handleErrorcould receive all errors with something like anexpected: true | falseproperty. That would allow developers to centrally log, inspect, and debug expected errors during development, while still preserving the distinction between expected and unexpected failures.This would make it much easier to answer questions like:
The main goal is not to change runtime behavior for users, but to give developers a single hook for observability and debugging.
Alternatives considered
A custom wrapper around
error(...)could be used to add logging or tracing.However, in an existing codebase this would likely require a large refactor, especially if the
error(...)pattern is already used in many places. A built-in solution throughhandleErrorwould be much more ergonomic and consistent.It could also be a dedicated hook.
Importance
would make my life easier
Additional Information
Based on this discussion here