A better approach to hook error handling?

[danawoodman]

I may be missing something here, but from my current understanding, there is no cannonical way to handle errors within hooks themselves?

For example, I have 4 hooks that are chained together with sequence. If any one of these hooks throws an exception the entire application chain breaks down and my users get a 500 error page.

On my initial investigation I made the assumption handleError would catch this, but on further looking (and Discord chat with Rainlife), it appears that the only approach to handling errors in a hook is to manually return a Response?

I would suggest/propose a more elegant system of handling these exceptions, so if you have anything non-trivial in a hook (like auth for example), the odds you hit an error are relatively high, and having to wrap everything in try/catches and manually returning raw Response objects feels clunky and maybe a better API could be provided?

Thinking out loud:

• Could handleError catch these hook exceptions? That is what I assumed first, and I think its reasonable other people would assume the same
• If not, could we have errors propagate to an error catcher hook with sequence like sequence(hookA, hookB, hookC, errorHandlerHook)?
• Perhaps a handleHookError helper method?

I'm sure there are technical reasons that these things may not exist/work this way, but as a consumer, this feels like a rough/unfinished part of the API.

Anyways, just putting my $0.02 out there, apologies if this has been discussed elsewhere but I did some looking and couldnt come up with much.

[eltigerchino]

Unexpected errors in handle are currently designed to return raw JSON or a HTML fallback page according to the docs.

https://kit.svelte.dev/docs/errors#responses

I believe you can also use the error, redirect, and json helpers to return a Response in your hooks.

https://kit.svelte.dev/docs/modules#sveltejs-kit

It's only rendering errors from load, etc. that use the handleError function

[danawoodman]

Yeah, I think you're right. The main takeaway of my post above is to highlight that this is an area where Kit doesn't really give you any guidance or tooling to make this a more enjoyable experience. At a minimum, a way to wrap a chain of hooks would be great, but it appears there isn't a clear way to approach this.

[eltigerchino]

Perhaps something like this:

/**
 * @param {import('types').Handle} handle
 * @param {import('./types').HandleErrorCallback} callback
 * @returns {import('types').Handle}
 */
export function handleHookError(handle, callback) {
	return async ({ event, resolve }) => {
		try {
			return await handle({ event, resolve });
		} catch (error) {
			return await callback({ error, event });
		}
	};
}

// types.d.ts
import { MaybePromise, RequestEvent } from 'types';

export interface HandleErrorCallback {
	(input: { error: unknown; event: RequestEvent }): MaybePromise<Response>;
}

// +hooks.server.js
export const handle = handleHookError(sequence(hookA, hookB, hookC, errorHandlerHook));

If you submit a feature request issue for this, I could try implementing a PR for a more official way about this rather than a helper function.

Although, the current naming is a bit confusing. handleError should be handleResolveError
and this new one would be ... handleHandleError ...? which is more accurate than handleHookError but sounds awful.

[danawoodman]

haha yeah that wouldn't be the best naming, but I like the general approach. Giving people a canonical way to handle hook errors would be great.

[danawoodman]

Created a ticket to track the suggestion #8797

[danawoodman]

Rich just mentioned there is an existing bug for handleError not handling hook errors, guess it is intended behavior :) #8797 (comment)