[fix] Handle throw error/redirect in +server.js

[dummdidumm]

Fixes #5993

This results in a (in my opinion correct) change in behavior: If you throw an error, you will no longer have the message rendered in the nearest +error.svelte, instead it's just blank text, which is what I'd expect from querying a regular endpoint.

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

• It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
• This message body should clearly illustrate what problems it solves.
• Ideally, include a test that fails without this PR but passes with it.

Tests

• Run the tests with pnpm test and lint the project with pnpm lint and pnpm check

Changesets

• If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpm changeset and following the prompts. All changesets should be patch until SvelteKit 1.0

[changeset-bot]

🦋 Changeset detected

Latest commit: 071d372

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@sveltejs/kit	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[dummdidumm]

Should this be converted into a Response, too? If it isn't this means unexpected errors get a regular "page" treatment and they are rendered within possible +error.svelte pages which seems wrong.

[Rich-Harris]

I think so, yeah

[Rich-Harris]

though actually... i wonder if that should happen at the bottom of respond. We already have a TODO comment there asking this exact question.

that way we get all the options.handle_error and sanitization logic centralised

[Rich-Harris]

gah, ok that's not possible because we want to render an error page if user code errors in handle (at least, that's the decision we made at some point in the past).

i do feel like there's some opportunities for simplification around error handling generally. might noodle in a separate PR. will merge this in the meantime though, no point in delaying it