createResource swallows error

[mathieuprog]

Describe the bug

Errors happening in the fetcher of the createResource seem to be swallowed:

window.addEventListener('unhandledrejection', (e) => console.error(e));
window.addEventListener('error', (e) => console.error(e));

function getCurrentUserResource() {
  const [currentUser] =
    createResource<any>(
      async () => {
        console.log('hello!') // logs
        throw 'error'; // swallowed
      }
    );

  return currentUser;
}

getCurrentUserResource();

Your Example Website or App

Steps to Reproduce the Bug or Issue

Expected behavior

Expected to see the error in the console

Screenshots or Videos

No response

Platform

• OS: Windows
• Browser: Chrome 113
• Solid: 1.7.5

Additional context

No response

[atk]

Yes, errors are handled by either the error property of the resource or solid's error boundaries or onError/catchError. This is intended behavior.

[mattbdc]

I struggled a little with this a few weeks ago:

Example with error boundary:

https://playground.solidjs.com/anonymous/437aa0db-3914-4056-ae63-0e3f69e1636d

Example with no error boundary:
https://playground.solidjs.com/anonymous/7e65ed62-48c6-4ef0-baf7-e7a30f364f3f
If you don't want the error boundary then be careful with invoking the resource () . Test if .error is undefined.

[ryansolid]

Yeah this by design. Resources work off reads, and error in the UI where they are read. I think ultimately error boundaries should have a better design that doesn't immediately unmount. More like:

<ErrorBoundary>{
  (err) => /*... do stuff */
}</ErrorBoundary>

That way you always have the error where you can manage it. This is one of the 2.0 component changes we're evaluating.

Anyway. Current resolution is this is by design.

[mathieuprog]

I want all errors to be handled by my global listeners on error events and on promise rejection events, as they will send any error to an error reporting tool.

As you have mentioned, one option is to check the "error" property of the resource, so I created an effect.

This is my code simplified:

const [userResource, { refetch }] = // ...

createEffect(() => {
  if (userResource.state === 'errored') {
    // allows the event to reach the global listener on error events
    setTimeout(() => { throw userResource.error }, 0);
  }
});

Note that I need to use setTimeout here because if I don't, I noticed that throwing directly from an effet will break the other createEffect, i.e. they will not run.

This seems to work fine but I noticed an issue.

I have these two global listeners:

window.addEventListener('unhandledrejection', (e) => handleErrorEvent(e));
window.addEventListener('error', (e) => handleErrorEvent(e));

The listener on unhandledrejection will sometimes run, sometimes not.

So sometimes I end up with a promise rejection event + error event (the rethrow in the settimeout), sometimes only the error event.

[snnsnn]

setTimeout is a big no in a syncronous reactive system that is why you are getting that inconsistent behavior. All you need is an ErrorBoundary in the outer scope the resource.

[mathieuprog]

@snnsnn Without writing any setTimeout, the listener on unhandledrejection is called about 1 time on 3 on my machine when a GET http://localhost:4001 net::ERR_CONNECTION_REFUSED error occurs, as the server is purposely not running to test the error handling on the client).
I do not understand why I have an inconsistent behavior.

[mathieuprog]

Sorry for the noise; I wanted to share an update as I found the cause of having intermittent promise rejection events, while using createResource.

It's because I was initiating a fetch request before the createResource call. The createResource fetcher would use that promise. Something like that. This caused some unpredictable behavior (which I'm unable to understand, as the createResource call is called in the synchronous execution and it shouldn't be something like a timing issue).
Anyway I refactored the code, ty.