Same Code when pasted in editor shows error logs in console.
Can anyone explain what's the reason? In case of resources If the error is handled then why in browser console I am seeing the error? and if the execution is immediate then why we need a ErrorBoundary later or handle the error once again when called the signal data() in a subscriber context.


20 Replies
Math.random()<2
is always trueYes I know that! Later I just realized no matter what modern browsers will throw these red marks even they don't have to.
Like if the error boundary was catching them why they are exposed in the console?
Are you sure? They only do that when you throw
Maybe a component is always throwing when rendering it
Well the codebase is in front of your eyes. Try the example in playground and in ide if you have time.
Normally there is no reason from my perspective for which browser showing the red marks
No, like, I know why it's happening
err()
gets called on initialization thanks to createResource
, and so err()
throws, so you get an errorHmm I was very confused regarding this. Like if I use a effect now above the error boundary the error boundary stops catching the error for some reason. If it was triggered during initialization then why that phenomena happens?
Is it like 2 different flows are created? Consuming inside subscribe context and normal trigger?
No, it's because the error boundary only triggers when there are rendering errors, not in functions that do other things apart
Also, async functions are not in the tracking scope of the caller's, so we can say
err()
is being executed in another flow
So yeah, you're kinda rightI see. It's really confusing. Like normally error or not , already is ensured by executing immediately as soon as the resource is created.
But still if I using it inside a subscribe context it's acting like who will subscribe first will get the error as after that you need to reset the resource.
So if we are using an effect that's consuming the error before the error boundary the error boundary fails to act upon that error
Giving me the same confusion of big react state managements. Lol
Yeah, that's async for you :p solid executes whatever procedurally, not like react where everything just runs whenever
I think I found the important bit:
However, an important note is that errors occurring outside the rendering process, such as in event handlers or after a setTimeout, are not caught by error boundaries.
Error boundary - Solid Docs
Documentation for SolidJS, the signals-powered UI framework
so yeah, errors in async and errors in the regular flow behave very differently
That's why the signal
createResource
returns has the error
prop, because you can't actually tell nor react when an error has occurred in that async context, so they give you that prop so you have something you can actually trackIn that sense in solid we can't avoid red flags in console?
Because we will throw error so that resources can change their state to error. But for that no one is handling our async function error
So those red patches become unavoidable.
Even though application is working
i see what you say, let me play a bit
ah, what a nuance, that's why it was working with my code
because i had a problem where the red thing never showed on the console, and i needed it to show that (so the opposite problem as you)
but without further ado, this is what i did:
<ErrorBoundary fallback={(err, reset) => <div>I am error</div>}>
the error shows no more
and by reading yet again what you said, i'm realising you were right all along
it's just this nuanceAnd I was wrong:
The <ErrorBoundary> component catches errors that occur during the rendering or updating of its children and shows a fallback UI instead. This includes: - Errors that occur while rendering JSX. - Errors that occur within createEffect, createMemo, and other state management primitives. - Errors that occur within createResource and other asynchronous state management or data-fetching primitives.It also catches errors thrown by async primitives
<ErrorBoundary> - Solid Docs
Documentation for SolidJS, the signals-powered UI framework
My best guess is that there's an internal try-catch, and the caught error is passed to the fallback function
But if you don't provide one and instead a JSX Element, I guess the error just bubbles up
@Madaxen86 I have a nuance here that I can't explain myself, so I was curious if you know something about it:
When an
ErrorBoundary
catches an error and you handle it via a function, it silences the error in the dev console
But when you just put a JSX Element as the fallback, the error shows up in the console
Why this inconsistent behaviour?
It will only log in DEV so that the error does not get swallowed and you as the dev knows what happened:
the line in the ErrorBoundary comp
f is the fallback
Oh wow, that is actually nice
Thanks!
Oh! Solid was taking care of devs! Didn't notice the src code though even it's open source! That's how lazy I am being now a days! Haha.
Solid does this.
React runs useEffect twice 😭