What is the purpose of "throw error" in +server endpoints?

[danawoodman]

Maybe I'm dense (very likely), but what is the purpose/value of throw error(...) in a +server.js file?

Right now, if you throw error in an +server endpoint your client, which likely expects JSON in 90% of the cases, will barf on the string response. It took me (an embarrassingly) long time to figure out that throw error was just returning a string and not some structured error object as I was expecting/hoping.

export const GET: RequestHandler = (req) => {
	// This doesn't seem very helpful?
	throw error(422, "Don't send me that junk");

	// Do I have to do this every time I have an error?
	return new Response(JSON.stringify({ error: "Don't send me that junk" }), {
		headers: { "Content-Type": "application/json" },
	});
};

You can of course return a new Response(...) with error, but that gets clunky real quick.

I also tried doing a throw error(422, JSON.stringify({ error: "..." })) type response but of course it is just sent as text/plain not application/json and I don't see a way to change that(?)

Is there a planned better way to throw error that is an actual convenience method for +server endpoints or do we need to implement this in userland (hope not 😅). As it stands, it seems throw error on the server is largly useless for most people's use cases (eg. JSON or other type of response beside plain text).

Excuse me if this has been posted before, but I did a search of issues/discussions and don't see much on the subject.

[repsac-by]

import { json } from '@sveltejs/kit';

export const GET: RequestHandler = (req) => {
	return json({ error: "Don't send me that junk" }, { status: 422 });
};

[danawoodman]

Wait, this is a thing? Didn't realize it was hiding over there...

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

Thanks for pointing this out 👍

[AlexRMU]

Really, why throw? Why not make redirect and error a constructor like json?

[danawoodman]

Redirect is built in and in the documentation expects you to "throw". I'm just wondering what the point of it is in +server files. It makes sense in +page/+page.server a lot more

[AlexRMU]

I mean that json needs to be returned and the error and redirect should be thrown for some reason

[danawoodman]

I believe Rich explained why this is on the latest changes. But for a +server page I don't see how they help the developer much since throw error() just returns a plain text response which is like 99% of the time not what you want.

[0gust1]

I don't have the exact response...

But I just changed our OAuth2 auth callback endpoint from src/routes/callback/+server.ts to src/routes/callback/+page.server.ts. This endpoint only throwq redirect (authent+authorization ok) or throw error (authorization not ok).

In the file, I just renamed the export const GET: RequestHandler = async (event)=>{...} function to export const load: PageServerLoad = async (event)=>{...}), and now, in case of an authorization error, we get it in the src/routes/+error.svelte error page instead of having a raw text in a white page. Felt good and nice !

edit: ah and thanks for your svelte content/tips on twitter, nice and useful snippets :)

[DrDanRyan]

I wrote a helper fetch_json function to be used in my components that works well with throw error

export default async function fetch_json(url, body, method) {
	const response = await fetch(url, {
		method,
		headers: { accept: "application/json" },
		body: method === "GET" ? undefined : JSON.stringify(body)
	});
	if (response.ok) {
		return response.json();
	} else {
		let err = await response.text();
		throw err;
	}
}

Then I wrap the await fetch_json call in a try/catch block in the svelte component that is calling it to do something with the error message. I do admit that it was a frustrating process to figure out that I needed to parse error responses with .text() instead of .json(), but once I realized that this solution seems to work well.

As a side note, I have decided to never use throw redirect in a +server.js endpoint. Instead, I return the relevant information encoded as json that will be needed to call goto from the client.

In the case where no information needs to be returned to the client I use return json(null) in +server.js endpoints.

[janzheng]

ok I'm using throw redirect(...) now but if I do that in a try / catch block, my catch block catches it as an error... are we not supposed to throw redirects and still be able to catch errors?

[DrDanRyan]

You are right that throw redirect triggers the catch block. You should just move the redirect to after the try/catch block if you want to catch errors. Most of my use of throw redirect happens as the first line of a load function to redirect unauthorized users to login. If I want to redirect after a fetch call to a +server.js endpoint, I do this in the browser with goto after the Response with ok status is received.