Confusing semantics of throw error, return invalid, throw redirect

[DePasqualeOrg]

I'm trying to migrate my SvelteKit projects to the latest version, and I'm confused by the semantics of throw/return with error, invalid, and redirect in the load functions. I also can't find examples in the documentation for how to use them. Can someone help me understand the reasoning behind the choice of throw or return here? And what's the difference between invalid and error?

[eltigerchino]

1. invalid

This one's used for returning validation information in a form action. It's not used in any load functions.
https://kit.svelte.dev/docs/form-actions#anatomy-of-an-action-validation-errors

2. error

You'll want to use throw error(400, "your reason") for expected errors.
For example, 401 Unauthorised when a user fails to log in. You expect this error to happen.

You can use these in a load function or in a +server endpoint for GET, POST, etc.
https://kit.svelte.dev/docs/load#errors

3. redirect

Similar semantics as error.
https://kit.svelte.dev/docs/load#redirects

4. Why throw instead of return?

I'm not smart enough to be in the know, so I'll just make my own assumptions:

1. It allows the load function to have a specific return type instead of trying to include all the different data shapes that fit the unexpected error, expected error, redirect, return data scenarios.

2. Previously, when I wanted to create a function to do authorisation checks and return an error / redirect, I would have to do this:

// +page.server.ts
import { validateToken } from "./utils";
export const load = ({ cookies }) => {
  const isInvalid = validateToken(cookies);
  if (isInvalid) return isInvalid;
};

// utils.ts
export const validateToken = (cookies) => {
  ...
  if (!token) {
    return { status: 300, location: '/login' }
  }
  
  if (invalidToken) {
    return { status: 401, body: { message } }
  }
  
  return null
}

Now I can do this:

import { validateToken } from "./utils";
export const load = ({ cookies }) => {
  validateToken(cookies);
};

// utils.ts
export const validateToken = (cookies) => {
  ...
  if (!token) {
    throw redirect(307, '/login')
  }
  
  if (invalidToken) {
    throw error(401, message)
  }
}

Big relief when I want to include the validateToken function in a number of different routes.

[DePasqualeOrg]

Great, thanks! This clears up my confusion.

[vhscom]

4. Why throw instead of return?

Note SvelteKit 2.0.0 removed throw and did not add an early return for SvelteKit redirect and error function calls.

[joshnuss]

I still wonder about using throw instead of return.

Generally, exceptions should only be used for truly exceptional situations.

I think of exception pathways like a service road next to a highway. If we put regular traffic on the service road, we no longer have a service road.

Also, it means redirect and error logic could be deeply nested in code, which makes code harder to reason about.
ie call some code, and it throws a redirect, then it's confusing where the redirect came from.

[eltigerchino]

These are good points. Perhaps some Svelte maintainers could explain the reasoning for this. Maybe it's something framework specific?

[yousufiqbal]

Also using throw error() inside try block of try/catch is impossible now. (See my other comment below)

[dummdidumm]

error is designed for the service road, it's an exception and is treated as one, just one that doesn't end up in handleError. redirect is somewhat of a gray area, but it's also an interruption of the flow (you're going elsewhere, you won't continue the data loading flow in the current load function), and the ergonomics are nicer.

Also using throw error() inside try block of try/catch is impossible now.

What's a use case for this? I guess it would help you if there was a way to know that the thing caught is coming from throw error(..) - e.g. something like if (isError(error)) {..}

[yousufiqbal]

Hey I used handleError for the first time and it sufficed all my needs. I don't need any try/catch now. Thanks for pointing out. Also the uncaught errors handling is a breeze now. Why the hell I was missing that!! Love you @dummdidumm

[joshnuss]

I guess it's maybe a preference thing?

I've always treated situations like "unauthorized", "invalid request" and "record not found" with normal control flow statements.
For me, an exceptional error is something that rarely happens, like "out of memory", "out of disk space", "encryption failed".

But this is just my preference,