breaking: tighten up error handling

[dummdidumm]

Introduces status and message to handleError which default to 500 and "Internal Error". Introduces a NonFatalError object that is used internally and is used to convert to more specific status/message objects. It's used everywhere where we can reasonably assign a non-500 status code.

closes #11287

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. Changesets that add features should be minor and those that fix bugs should be patch. Please prefix changeset messages with feat:, fix:, or chore:.

[changeset-bot]

🦋 Changeset detected

Latest commit: 231f212

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

This PR includes changesets to release 3 packages

Name	Type
@sveltejs/adapter-vercel	Major
@sveltejs/adapter-node	Major
@sveltejs/kit	Major

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

[Rich-Harris]

Instead of introducing a NonFatalError (which is a bit of a weird name) and expecting users to do instanceof checks, why don't we just add status and message properties to handleError?

export function handleError({ error, status, message }) {
  const id = crypto.randomUUID();

  report(id, error);

  return {
    id,
    message // e.g. 'Not Found' for things we threw ourselves, 'Internal Error' for unexpected stuff (as today)
  };
}

[dummdidumm]

We still need the class internally to distinguish it before passing it to handleError though, else how do we know if we can show the message? So if we need it we might aswell surface it.
Having status and message part of the API feels nicer though, I give you that (we could extract status and message from the NonFatalError before passing it to handleError)

[dummdidumm]

Was the try-catch really only applied because of the known throw inside, or was it a "who knows let's better be extra safe" precaution?

[Rich-Harris]

Because of the known throw inside. It's a bad practice to wrap code that can't error