sveltejs/kit · warning
The `status` property of `handleError` is deprecated. Use `e
Error message
The `status` property of `handleError` is deprecated. Use `error.status` for expected and framework errors, or `500` for unexpected errors.
What it means
The object passed to the `handleError` hook carries a legacy `status` property implemented as a getter that warns on access. It is deprecated because status semantics differ between expected/framework errors and unexpected errors; developers should use `error.status` or hardcode 500.
Source
Thrown at packages/kit/src/utils/error.js:57
* @param {unknown} error
*/
export function get_status(error) {
return error instanceof HttpError || error instanceof SvelteKitError ? error.status : 500;
}
/**
* Adds development-only compatibility accessors for the former top-level `status` and `message`
* properties of the `handleError` hook input.
* @template {object} T
* @param {T} input
* @param {{ status: number; message: string }} fallback
* @returns {T}
*/
export function add_deprecated_handle_error_properties(input, fallback) {
Object.defineProperties(input, {
status: {
get() {
console.warn(
'The `status` property of `handleError` is deprecated. Use `error.status` for expected and framework errors, or `500` for unexpected errors.'
);
return fallback.status;
}
},
message: {
get() {
console.warn(
"The `message` property of `handleError` is deprecated. Use `error.message` for expected and framework errors, or 'Internal Error' for unexpected errors."
);
return fallback.message;
}
}
});
return input;
}
View on GitHub (pinned to 03f1687fe6)
Solutions
- Replace `error.status` in the hook with logic: use `error.status` for HttpError/SvelteKitError, else 500
- Destructure only `message` or use the second (fallback/envelope) argument's fields deliberately, accepting the deprecation temporarily
- Update error-reporting code to log `error.status ?? 500` from the actual error
Example fix
// before
export const handleError = ({ error, status }) => ({ message: error.message, status });
// after
export const handleError = ({ error }) => ({
message: error.message,
status: error instanceof HttpError || error instanceof SvelteKitError ? error.status : 500
}); Defensive patterns
Strategy: type-guard
Validate before calling
// compute status yourself instead of reading deprecated prop
function resolveStatus(error) {
return error && typeof error === 'object' && 'status' in error && typeof error.status === 'number'
? error.status
: 500;
} Type guard
function hasOwnStatus(error) {
return error instanceof Error && 'status' in error && typeof error.status === 'number';
} Prevention
- Never read `status` directly off the handleError argument
- Use instanceof checks for HttpError/SvelteKitError to get real status
- Update error reporting SDKs to avoid serializing deprecated getters
When it happens
Trigger: Reading `status` on the first argument inside a `handleError` hook in hooks.server.js (the getter installed by `add_deprecated_handle_error_properties` is evaluated).
Common situations: Old hook implementations migrated from earlier SvelteKit versions; error-reporting integrations that serialize the whole error object including `status`; copying hook examples from outdated tutorials.
Related errors
- The `message` property of `handleError` is deprecated. Use `
- To use an async `handleError` hook to handle errors that occ
- Failed to get response header "set-cookie" — it must be incl
- Use `event.cookies.set(name, value, options)` instead of `ev
- Reading `config.kit` inside adapters is deprecated — it shou
AI-assisted analysis of sveltejs/kit@03f1687fe6 (2026-09-02).
Data as JSON: /api/errors/4306b55559b2e70a.
Report an issue: GitHub.