try block, like error boundary
See original GitHub issueIs your feature request related to a problem? Please describe.
I wonder would it possible to have a {#try}
logic block, such that anything goes inside, if error would be handled in the {:catch}
block, eg:
{#try}
<Component />
{:catch}
<div>Fallback uI </div>
{/try}
if an error thrown during init / update in <Component />
, then will see the Fallback UI instead.
Describe the solution you’d like A clear and concise description of what you want to happen.
Describe alternatives you’ve considered A clear and concise description of any alternative solutions or features you’ve considered.
How important is this feature to you? Note: the more honest and specific you are here the more we will take you seriously.
Additional context Add any other context or screenshots about the feature request here.
Issue Analytics
- State:
- Created 4 years ago
- Reactions:74
- Comments:13 (2 by maintainers)
Top Results From Across the Web
Error boundaries vs. try...catch - Educative.io
With error boundary, if there is an error, you can trigger a fallback UI; whereas, with try…catch, you can catch errors in your...
Read more >Error Boundaries - React
Error boundaries are React components that catch JavaScript errors anywhere ... Error boundaries work like a JavaScript catch {} block, but for components....
Read more >Handling JavaScript errors in React with error boundaries
Error boundaries operate like the catch block in the JavaScript try...catch statement with a couple exceptions: they are declarative and, ...
Read more >React: Catching Errors using Error Boundaries - Bits and Pieces
In JS code, we use the try-catch block to catch errors and handle them gracefully. ... Error boundaries work like JS catch {}...
Read more >Catching Errors in React with Error Boundaries
These limitations might sound severe, but most of the time they can be worked around by using try-catch and a similar hasError state....
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
I voted down for this. I don’t understand why this
try & catch
logics should be handled in the Svelte templates.If a GraphQL response might be an error (as @marcus-sa 's example), it should be handled in the API Endpoint sections where you sent the request.
If the post title might be an undefined or null (as @thedivtagguy 's example), your backend should return a
""
(empty string) instead of making the property disappear from the Object. The response structure should be strongly fixed instead of over dynamic.If you are still aiming for this goal, try to fill your
title
when you received the response with.map
:Good idea.
Maybe something like this would benefit even more, depending on the error getting thrown. So basically like a
switch
statement for catching errors.