How to throw a 404 inside an element?

[ivands]

Describe the problem

We have our own api client. Not using remote functions.
The reason is caching, and calling our API inside a remote function would just add an extra network call to every api request.

But it's unclear how to throw a 404 inside our own client when a resource is not found.
So that SvelteKit knows to render the 404 page.
I did find a way to do this with remote functions.
But how can we do this using only "async svelte" and our own API client?

Describe the proposed solution

I can't find any docs on how to do this.
Would be nice if we had some docs on how to solve this problem.

Alternatives considered

No response

Importance

i cannot use SvelteKit without it

Additional Information

No response

[sacrosanctic]

But how can we do this using only "async svelte" and our own API client?

redirect to /404

Or you want to handle the error gracefully, then consider https://svelte.dev/docs/svelte/svelte-boundary

[ivands]

@sacrosanctic I'm still confused.
How can we redirect during rendering inside a component?
Cause the problem is that rendering happens client & server side.
Also, I don't really wanna redirect.
I wanna stop the rendering and show the 404 error page.
Just like when you throw a 404 error inside a remote function.

[ivands]

Example:

<script>
const post = await getPost() // not a remote function
if(!post) {
 // What now?
}
</script>
<h1>{post.title}</h1>

[teemingc]

In SvelteKit 3 you should be able to throw your own Error object and handle that in a client-side handleError https://next.svelte.dev/docs/kit/errors#Unknown-errors
SvelteKit 3 also uses +error.svelte pages for errors thrown during async rendering https://next.svelte.dev/docs/kit/errors#Error-boundaries

[sacrosanctic]

<script>
	const getName = async () => {
		throw new Error('bleh')
		return 'hi'
	}
</script>

<svelte:boundary>
	{#snippet failed(error)}
		{error}
	{/snippet}

	{await getName()}
</svelte:boundary>

REPL

Alongside what teemingc said, you'll get better hooks in sk3. It the pattern is more or less the same now.

[Navesz]

On SvelteKit 2.x (2.70.3 is still latest on npm), you can get this today with the experimental flag whose behaviour becomes the default in SvelteKit 3. Three pieces:

1. Enable the flag

// svelte.config.js
export default {
  compilerOptions: { experimental: { async: true } },
  kit: {
    // adapter: ...,
    experimental: { handleRenderingErrors: true }
  }
};

2. Throw error() inside the awaited function

<script>
  import { error } from '@sveltejs/kit';
  import { page } from '$app/state';
  import { getPost } from '$lib/api'; // your own client

  async function getPostOr404(slug) {
    const post = await getPost(slug);
    if (!post) error(404, 'Post not found');
    return post;
  }

  const post = await getPostOr404(page.params.slug);
</script>

<h1>{post.title}</h1>

3. Key the root layout (workaround for a 2.x bug, see below)

<!-- src/routes/+layout.svelte -->
<script>
  import { page } from '$app/state';
  let { children } = $props();
</script>

{#key page.url.pathname}
  {@render children()}
{/key}

What I saw

	flag off	flag on	flag on + {#key}
SSR of a missing post	HTTP 404, root +error.svelte	HTTP 404, nearest +error.svelte	same
Client navigation to a missing post	blank page, 3 unhandled rejections	nearest +error.svelte, page.status 404	same
Then link or history.back() to /	n/a	error page stays, page.status 200	home page renders

Why

• SSR works without the flag. A render error ends up in this catch, which uses the HttpError's status. On the client there is no boundary, so the error is never handled.
• The flag adds the boundaries. The generated root wraps each level that has an +error.svelte in <svelte:boundary> (write_root.js L11, L39). transformError then sets page.error/page.status from what you threw, on the client and the server. One caveat: the docs note on rendering errors says page is not updated for rendering errors, while this 2.x client code does set page.status/page.error, and that is what I saw. Reading the error from the error prop in +error.svelte is the documented route.
• The stuck error page is Client navigation leaves stale +error.svelte mounted after remote query render error with experimental handleRenderingErrors #15694. A failed boundary is never reset: client navigation only calls root.$set(...). The fix (fix: reset sveltekit-controlled error boundaries on navigation #16296) and the flag's removal (breaking: remove experimental.handleRenderingErrors flag #16265) were merged into version-3 only. client.js and write_root.js are identical in 2.69.3 and 2.70.3. The {#key} workaround comes from that issue. Its cost: everything under the root layout is destroyed and recreated on every pathname change.
• Why a helper instead of an inline if. With the inline version of your example (const post = await getPost(); if (!post) error(404), then {post.title}), SSR still gave 404. On client navigation, though, I got a 500 with Internal Error. Without the flag, the first error logged was Cannot read properties of null (reading 'title'), which suggests the template read post.title before error() took effect. Throwing inside the awaited function avoided that in every run. I saw this happen but did not trace it in the Svelte compiler.

Tested

• @sveltejs/kit 2.69.3 + svelte 5.56.5, and 2.70.3 + 5.57.0
• vite 8.3.0, vite-plugin-svelte 7.3.0, adapter-node 5.5.7, experimental.async on
• Run with node build (both versions) and vite dev (2.69.3), in headless Edge

Not tested: remote functions, or errors thrown from a layout.

If the full remount from {#key} is too costly for you, it may be worth asking on #15694 whether #16296 can be backported to 2.x.

[AIVIETNAM-AIO-felixdoit]

I tested this on SvelteKit 2.70.3 with experimental.async and handleRenderingErrors enabled.

Throwing error(404, 'Post not found') inside the awaited helper correctly renders +error.svelte during both SSR and client-side navigation.

I can also reproduce the stale error boundary issue after navigating back to a valid route. Wrapping the root layout with {#key page.url.pathname} fixes it, although it causes the layout subtree to remount.

Btw tks for documenting the workaround, this helped clarify the difference between throwing during async rendering and handling the missing resource directly in the component.