feat: add error boundaries #14211

trueadm · 2024-11-07T18:56:02Z

This PR adds support for error boundaries to Svelte. Specifically, it adds <svelte:boundary>, which is a special element that can capture errors that occur from within its subtree during client rendering (error boundaries are no-ops during SSR).

The error boundary will capture all errors that occur in any effects (such as $effect and $effect.pre) within its subtree, as long as the code is run synchronously (code in an async or setTimeout will not be captured). <svelte:boundary> can report errors with using onerror, this can be a place where the error can be re-thrown to the next boundary:

Note: Errors in event handlers are not captured.

<script>
  function throw_error() {
    throw new Error('test')
  }
</script>

<svelte:boundary onerror={(e) => console.log('error caught')}>
  {throw_error()}
</svelte:boundary>

In addition, some fallback content can be rendered when an error occurs in a boundary using the failed snippet prop:

<script>
  function throw_error() {
    throw new Error('test')
  }
</script>

<svelte:boundary>
  {throw_error()}

  {#snippet failed(error)}
    <div>An error occurred! {e}</div>
  {/snippet}
</svelte:boundary>

Additionally, a reset function is passed as the second argument to both onerror and the failed prop:

<script>
  function throw_error() {
    throw new Error('test')
  }
</script>

<svelte:boundary>
  {throw_error()}

  {#snippet failed(error, reset)}
    <div>An error occurred! {e}</div>
    <button onclick={reset}>Try again</button>
  {/snippet}
</svelte:boundary>

Feel free to play around with them on the playground.

Closes #3733, closes #14054

changeset-bot · 2024-11-07T18:56:06Z

🦋 Changeset detected

Latest commit: c468c6d

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

This PR includes changesets to release 1 package

Name	Type
svelte	Minor

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 · 2024-11-07T18:56:37Z

preview: https://svelte-dev-git-preview-svelte-14211-svelte.vercel.app/

this is an automated message

github-actions · 2024-11-07T18:57:24Z

Playground

pnpm add https://pkg.pr.new/svelte@14211

tweak tweak again retry -> reset tweaks add tests tweaks tweaks tweaks more tests more tests and tweaks comments tweak tweak tweak tweak tweak

tweak tweak tweak more fixes tweak tweak more fixes changeset

.changeset/polite-peaches-do.md

packages/svelte/elements.d.ts

JReinhold · 2024-11-07T19:46:46Z

Can this be feature detected?
Say I'm building a library that will support Svelte 5.0.0 and up, and I want to progressively enhance the experience, with an error boundary if available, or just no handling if the project has Svelte v5.0.0.

Maybe there's a general way to feature detect <svelte:X> components that I just don't know about?

Co-authored-by: Simon H <5968653+dummdidumm@users.noreply.github.com>

levibassey · 2024-11-07T20:03:48Z

Was kinda expecting the api to look like this

{#boundary}
    ...
{:else e}
    <div>An error occurred! {e}</div>
{/boundary}

Maybe even

{#try}
    ...
{:catch e}
    <div>An error occurred! {e}</div>
{/try}

Aren't error boundaries more like, control flow?

trueadm · 2024-11-07T20:06:11Z

Was kinda expecting the api to look like this
{#boundary}
    ...
{:else}
    ...
{/boundary}
Maybe even
{#try}
    ...
{:catch}
    ...
{/try}
Aren't error boundaries more like control flow?

What if you want to re-throw an error, or log an error to sentry? What if you want to render the error message somewhere else? We explored this API and it has too many drawbacks. Not to mention, <svelte:boundary> can support other usages in the future other than just capturing errors.

paoloricciuti · 2024-11-07T20:06:40Z

Can this be feature detected? Say I'm building a library that will support Svelte 5.0.0 and up, and I want to progressively enhance the experience, with an error boundary if available, or just no handling if the project has Svelte v5.0.0.

Maybe there's a general way to feature detect <svelte:X> components that I just don't know about?

What are you thinking about? Considering this should basically be for unexpected errors how would know about it help a library?

dominikg · 2024-11-07T20:26:53Z

Can this be feature detected? Say I'm building a library that will support Svelte 5.0.0 and up, and I want to progressively enhance the experience, with an error boundary if available, or just no handling if the project has Svelte v5.0.0.
Maybe there's a general way to feature detect <svelte:X> components that I just don't know about?

What are you thinking about? Considering this should basically be for unexpected errors how would know about it help a library?

lets say storybook used it, and a user using storybook is on svelte 5.1, if we add this with 5.2, storybook either has to release a breaking change to add a boundary to their stories or feature detect it so that <svelte:boundary> does not trip the svelte 5.1 compiler to not break their users.

@JReinhold you should be able to use the exported version from svelte/compiler and compare that its equal or larger to the first release of this feature.

Leonidaz · 2024-11-07T20:30:10Z

What if you don't want to show anything from inside the boundary if an error occurs, and instead use a fallback?

Right now it seems that whatever has a chance to get rendered / added to the dom, stays in, which could result in a broken state. I added an {#if} with a reactive error var but it doesn't seem to matter.

Demo from a commit in this pr

trueadm · 2024-11-07T20:33:52Z

What if you don't want to show anything from inside the boundary if an error occurs, and instead use a fallback?

Right now it seems that whatever has a chance to get rendered / added to the dom, stays in, which could result in a broken state. I added an {#if} with a reactive error var but it doesn't seem to matter.

Demo from a commit in this pr

Looks like a bug, looking into that now.

Update:fixed!

Ocean-OS · 2024-11-07T20:47:40Z

I like this, however, like other people, I am not sure about the execution of the idea; maybe it could be a logic block, as the svelte: elements usually don't have children, and are often meant more for data or compiler options instead of actual DOM-related functions. Additionally, it doesn't feel as "magical" as other Svelte features/elements to have to use a snippet for the fallback, instead of the fallback being declared in a separate part of the block (eg an "else" statement).
Also, if merged, shouldn't this close #3733?

trueadm · 2024-11-07T20:59:11Z

I like this, however, like other people, I am not sure about the execution of the idea; maybe it could be a logic block, as the svelte: elements usually don't have children, and are often meant more for data or compiler options instead of actual DOM-related functions. Additionally, it doesn't feel as "magical" as other Svelte features/elements to have to use a snippet for the fallback, instead of the fallback being declared in a separate part of the block (eg an "else" statement). Also, if merged, shouldn't this close #3733?

They compose far better than logic blocks. For example, you can create custom error boundaries for your app using the same snippet pattern:

<MyAppErrorBoundary>
  <Content />
  
  {#snippet failed(error)}
    <ErrorMessage {error} />
  {/snippet}
</MyAppErrorBoundary>

JReinhold · 2024-11-07T21:09:18Z

you should be able to use the exported version from svelte/compiler and compare that its equal or larger to the first release of this feature.

@dominikg Unless I'm misunderstanding you, I'm not sure this is true, since it happens at the compiler level. So even if you only have the boundary on a condition based on the version, the compiler will still try to compile it and fail. This will still fail in v5.1:

{#if false}
	<svelte:boundary>
		whoops
	</svelte:boundary>
{/if}

See https://www.sveltelab.dev/5doeu6jrx5dqxj1?files=.%2Fsrc%2Froutes%2F%2Bpage.svelte

paoloricciuti · 2024-11-07T21:11:22Z

you should be able to use the exported version from svelte/compiler and compare that its equal or larger to the first release of this feature.

@dominikg Unless I'm misunderstanding you, I'm not sure this is true, since it happens at the compiler level. So even if you only have the boundary on a condition based on the version, the compiler will still try to compile it and fail. This will still fail in v5.1:
{#if false}
	<svelte:boundary>
		whoops
	</svelte:boundary>
{/if}
See https://www.sveltelab.dev/5doeu6jrx5dqxj1?files=.%2Fsrc%2Froutes%2F%2Bpage.svelte

I guess you could have a component that just renders the children snippet and one that wrap in boundary and dynamically import based on the condition

trueadm · 2024-11-07T21:22:54Z

@Ocean-OS I'm not sure what you're trying to do in that example? Half the code is commented out, is it meant to be there? What am I looking for?

Leonidaz · 2024-11-07T21:46:33Z

What if you don't want to show anything from inside the boundary if an error occurs, and instead use a fallback?
Right now it seems that whatever has a chance to get rendered / added to the dom, stays in, which could result in a broken state. I added an {#if} with a reactive error var but it doesn't seem to matter.
Demo from a commit in this pr

Looks like a bug, looking into that now.

Update:fixed!

Awesome! @trueadm

One more thing I thought of, currently if an error occurs in the failed snippet itself it leads to an infinite loop and crashes. I thought that just in case, it would be cool if it could be handled in some kind of try / catch and re-thrown further up the component tree.

here's a repro of the error in the failed snippet

Ocean-OS · 2024-11-07T23:15:03Z

@Ocean-OS I'm not sure what you're trying to do in that example? Half the code is commented out, is it meant to be there? What am I looking for?

I was testing to see how many times the code inside the boundary would rerun, using a counter. I was primarily trying to see when the DOM tree was replaced in the boundary. The counter never ran, which made me think something was wrong, so I tried the same thing in an if statement, which didn't seem to work either. I then tried commenting the boundary out to see if it would change anything, which it didn't.

Ocean-OS · 2024-11-07T23:39:00Z

@Ocean-OS I'm not sure what you're trying to do in that example? Half the code is commented out, is it meant to be there? What am I looking for?

I was testing to see how many times the code inside the boundary would rerun, using a counter. I was primarily trying to see when the DOM tree was replaced in the boundary. The counter never ran, which made me think something was wrong, so I tried the same thing in an if statement, which didn't seem to work either. I then tried commenting the boundary out to see if it would change anything, which it didn't.

Nevermind, it appears this didn't work in the latest release either. Sorry for the confusion.

trueadm · 2024-11-08T00:19:57Z

@Leonidaz addressed your issue in a later commit

Leonidaz · 2024-11-08T03:30:34Z

addressed your issue

Amazing! 🤩 Everything works buttery smooth! Thank you!

Thiagolino8 · 2024-11-08T11:03:55Z

svelte:boundary is a confusing name, it's a boundary of what? a suspense boundary? client-server boundary?

dummdidumm · 2024-11-08T11:13:11Z

an error boundary, and possibly more in the future

benbucksch · 2024-11-08T17:21:41Z

I often want the component to handle its own errors, including all $: , e.g. showing an inline error. How would I do that with this proposal?

benbucksch · 2024-11-08T17:24:26Z

Does it catch all errors, including on:click event handlers throwing? This and $: are the most frequent source of errors.

I need the component to handle these errors, without adding try/catch in every single event handler and $: statement

AbhiPrasad

I work at Sentry on the JavaScript SDKs - this is exactly the kind of API we were hoping come from Svelte! Awesome job.

It would be nice to get a component stack (a stack trace with the component that threw, as well as the names and source locations of all its parent components) at time of error like we get with react error boundaries. In the react implementation they stitch together a synthetic stacktrace by walking the component tree and throwing errors. Not sure if a similar approach is viable here. Because the component stack is a synthetic stacktrace representing the component call chain, libraries like Sentry can parse it (and sourcemap it) to display in logging UI accordingly.

AbhiPrasad · 2024-11-08T17:22:57Z

packages/svelte/elements.d.ts

@@ -2026,6 +2026,10 @@ export interface SvelteHTMLElements {
 		[name: string]: any;
 	};
 	'svelte:head': { [name: string]: any };
+	'svelte:boundary': {
+		onerror?: (error: Error, reset: () => void) => void;


What do you think about adding a onreset prop here as well? There are some scenarios where executing a side effect could be useful.

I know users can reach in and wrap the reset method, but that feels like it introduces friction.

We already provide component stack traces on our errors during DEV, this PR actually extends this so the stack happens in more places too.

Awesome, I didn't realize we had the component stack on error.message, seems like it was implemented earlier! That's great, any error logging sdk can parse that and use right away.

Right now this component stack is attached to an error with define_property(error, 'message'... in handle_error. Could we evaluate defining it as a separate field on the error? This would make it easier for error logging to just grab and parse the field instead of having to read through error.message. It would also be nice to pass the component_stack into onerror callback so it can be used in userland (users don't have to parse error.message to get access to it).

Ocean-OS · 2024-11-08T17:30:32Z

I often want the component to handle its own errors, including all $: , e.g. showing an inline error. How would I do that with this proposal?

Basically, you'd put the component that might throw an error inside the boundary, and the error handling inside a snippet in the boundary. Here's an example:

<svelte:boundary>
<ComponentThatMightThrow />
{#snippet failed(error, retry)}
There was an error: {error}<br>
Try again? <button onclick={retry} >Retry</button>
{/snippet} 
</svelte:boundary>

Ocean-OS · 2024-11-08T17:32:09Z

I work at Sentry on the JavaScript SDKs - this is exactly the kind of API we were hoping come from Svelte! Awesome job.

It would be nice to get a component stack (a stack trace with the component that threw, as well as the names and source locations of all its parent components) at time of error like we get with react error boundaries. In the react implementation they stitch together a synthetic stacktrace by walking the component tree and throwing errors. Not sure if a similar approach is viable here. Because the component stack is a synthetic stacktrace representing the component call chain, libraries like Sentry can parse it (and sourcemap it) to display in logging UI accordingly.

I agree, it would be nice if it threw an actual Error instead of just the error message, so you would be able to get both the stack and the message.

Leonidaz · 2024-11-08T19:30:09Z

@trueadm

tested a few more use cases, potentially a couple more issues.

not sure if this is expected but re-throwing without any top boundary handlers doesn't seem to result in an error, nothing happens.

rethrow - no error

And not sure if this can be handled, two boundaries and the same error in both only causes the top one to error and to render the failed snippet.

same error, only one boundary triggered, second stuck in the broken state

trueadm · 2024-11-08T20:37:19Z

@Leonidaz Thank you so much for those test cases! I've fixed them and added regression test for both :)

Ocean-OS · 2024-11-08T20:59:36Z

I agree, it would be nice if it threw an actual Error instead of just the error message, so you would be able to get both the stack and the message.

@AbhiPrasad, it turns out it does have the error stack, here's an example.

packages/svelte/src/internal/client/runtime.js

AbhiPrasad · 2024-11-09T00:34:57Z

packages/svelte/elements.d.ts

@@ -2026,6 +2026,10 @@ export interface SvelteHTMLElements {
 		[name: string]: any;
 	};
 	'svelte:head': { [name: string]: any };
+	'svelte:boundary': {
+		onerror?: (error: Error, reset: () => void) => void;


Awesome, I didn't realize we had the component stack on error.message, seems like it was implemented earlier! That's great, any error logging sdk can parse that and use right away.

Right now this component stack is attached to an error with define_property(error, 'message'... in handle_error. Could we evaluate defining it as a separate field on the error? This would make it easier for error logging to just grab and parse the field instead of having to read through error.message. It would also be nice to pass the component_stack into onerror callback so it can be used in userland (users don't have to parse error.message to get access to it).

trueadm · 2024-11-09T10:04:42Z

Right now this component stack is attached to an error with define_property(error, 'message'... in handle_error. Could we evaluate defining it as a separate field on the error? This would make it easier for error logging to just grab and parse the field instead of having to read through error.message. It would also be nice to pass the component_stack into onerror callback so it can be used in userland (users don't have to parse error.message to get access to it).

@AbhiPrasad I've added the component_stack property to the error too. We don't want to overload the callback with extra arguments, so attaching to the error object itself seems the most ideal.

benbucksch · 2024-11-11T16:40:31Z

I often want the component to handle its own errors, including all $: , e.g. showing an inline error. How would I do that with this proposal?

Basically, you'd put the component that might throw an error inside the boundary, and the error handling inside a snippet in the boundary. Here's an example:
<svelte:boundary>
<ComponentThatMightThrow />
{#snippet failed(error, retry)}
There was an error: {error}<br>
Try again? <button onclick={retry} >Retry</button>
{/snippet} 
</svelte:boundary>

This is doesn't address the stated need of catching the error within the same component where the error appears. I cannot wrap every component (which handles its own errors) with another component.

Leonidaz · 2024-11-11T16:49:56Z

I often want the component to handle its own errors, including all $: , e.g. showing an inline error. How would I do that with this proposal?

Basically, you'd put the component that might throw an error inside the boundary, and the error handling inside a snippet in the boundary. Here's an example:
<svelte:boundary>
<ComponentThatMightThrow />
{#snippet failed(error, retry)}
There was an error: {error}<br>
Try again? <button onclick={retry} >Retry</button>
{/snippet} 
</svelte:boundary>
This is doesn't address the stated need of catching the error within the same component where the error appears. I cannot wrap every component (which handles its own errors) with another component.

@benbucksch You can wrap any part of your component markup with one or more boundaries.

trueadm changed the title ~~feat: adds error boundaries~~ feat: add error boundaries Nov 7, 2024

trueadm force-pushed the error-boundaries branch from 290dab2 to be4c2cd Compare November 7, 2024 18:57

trueadm force-pushed the error-boundaries branch from be4c2cd to ce5efe4 Compare November 7, 2024 18:57

feat: add error boundary support

007d5f3

tweak tweak again retry -> reset tweaks add tests tweaks tweaks tweaks more tests more tests and tweaks comments tweak tweak tweak tweak tweak

trueadm force-pushed the error-boundaries branch from ce5efe4 to d2e035b Compare November 7, 2024 18:58

tweak

f683ce2

tweak tweak tweak more fixes tweak tweak more fixes changeset

trueadm force-pushed the error-boundaries branch from d2e035b to f683ce2 Compare November 7, 2024 18:58

dummdidumm reviewed Nov 7, 2024

View reviewed changes

.changeset/polite-peaches-do.md Outdated Show resolved Hide resolved

dummdidumm reviewed Nov 7, 2024

View reviewed changes

packages/svelte/elements.d.ts Outdated Show resolved Hide resolved

trueadm and others added 2 commits November 7, 2024 19:50

Update packages/svelte/elements.d.ts

51e49be

Co-authored-by: Simon H <5968653+dummdidumm@users.noreply.github.com>

Update .changeset/polite-peaches-do.md

11b2ecd

Co-authored-by: Simon H <5968653+dummdidumm@users.noreply.github.com>

This comment was marked as spam.

Sign in to view

This comment was marked as off-topic.

Sign in to view

fix issue with rethrowing

10897ac

This comment has been minimized.

Sign in to view

trueadm added 2 commits November 8, 2024 00:15

handle fallback error

e6b6a68

handle fallback error

dc95bd3

trueadm added 2 commits November 8, 2024 01:01

add more test coverage

b9bc80d

more tests

cf11f58

kwangure mentioned this pull request Nov 8, 2024

try block, like error boundary #3733

Open

AbhiPrasad reviewed Nov 8, 2024

View reviewed changes

more bug fixes

4d8ad24

AbhiPrasad reviewed Nov 9, 2024

View reviewed changes

trueadm added 2 commits November 9, 2024 10:01

guard against non-errors

2c8dea6

add component_stack to error

5be2334

alternative approach

c468c6d

feat: add error boundaries #14211

Are you sure you want to change the base?

feat: add error boundaries #14211

Conversation

trueadm commented Nov 7, 2024 • edited by dummdidumm Loading

changeset-bot bot commented Nov 7, 2024 • edited Loading

🦋 Changeset detected

Rich-Harris commented Nov 7, 2024

github-actions bot commented Nov 7, 2024

JReinhold commented Nov 7, 2024 • edited Loading

levibassey commented Nov 7, 2024 • edited Loading

trueadm commented Nov 7, 2024

paoloricciuti commented Nov 7, 2024

dominikg commented Nov 7, 2024

This comment was marked as spam.

This comment was marked as spam.

This comment was marked as off-topic.

Leonidaz commented Nov 7, 2024

trueadm commented Nov 7, 2024 • edited Loading

Ocean-OS commented Nov 7, 2024 • edited Loading

trueadm commented Nov 7, 2024 • edited Loading

JReinhold commented Nov 7, 2024

paoloricciuti commented Nov 7, 2024

This comment has been minimized.

trueadm commented Nov 7, 2024

Leonidaz commented Nov 7, 2024

Ocean-OS commented Nov 7, 2024 • edited Loading

Ocean-OS commented Nov 7, 2024

trueadm commented Nov 8, 2024

Leonidaz commented Nov 8, 2024

Thiagolino8 commented Nov 8, 2024

dummdidumm commented Nov 8, 2024 • edited Loading

benbucksch commented Nov 8, 2024

benbucksch commented Nov 8, 2024

AbhiPrasad left a comment

Choose a reason for hiding this comment

AbhiPrasad Nov 8, 2024

Choose a reason for hiding this comment

trueadm Nov 8, 2024 • edited Loading

Choose a reason for hiding this comment

AbhiPrasad Nov 9, 2024

Choose a reason for hiding this comment

Ocean-OS commented Nov 8, 2024 • edited Loading

Ocean-OS commented Nov 8, 2024 • edited Loading

Leonidaz commented Nov 8, 2024

trueadm commented Nov 8, 2024

Ocean-OS commented Nov 8, 2024

AbhiPrasad Nov 9, 2024

Choose a reason for hiding this comment

trueadm commented Nov 9, 2024

benbucksch commented Nov 11, 2024 • edited Loading

Leonidaz commented Nov 11, 2024

trueadm commented Nov 7, 2024 •

edited by dummdidumm

Loading

changeset-bot bot commented Nov 7, 2024 •

edited

Loading

JReinhold commented Nov 7, 2024 •

edited

Loading

levibassey commented Nov 7, 2024 •

edited

Loading

trueadm commented Nov 7, 2024 •

edited

Loading

Ocean-OS commented Nov 7, 2024 •

edited

Loading

trueadm commented Nov 7, 2024 •

edited

Loading

Ocean-OS commented Nov 7, 2024 •

edited

Loading

dummdidumm commented Nov 8, 2024 •

edited

Loading

trueadm Nov 8, 2024 •

edited

Loading

Ocean-OS commented Nov 8, 2024 •

edited

Loading

Ocean-OS commented Nov 8, 2024 •

edited

Loading

benbucksch commented Nov 11, 2024 •

edited

Loading