Exceptions thrown in `mapSelect` function of `useSelect` hook should be reported in Sentry

[fluiddot]

Describe the bug
In a recently spotted Sentry issue, we've seen the following exception thrown in this line of the inserter menu:

Unhandled JS Exception: TypeError: undefined is not an object (evaluating 'Y.items')

Unfortunately, this exception doesn't give any clue about what happened as it's not expected that a call to the useSelect hook returns an undefined object. Investigating further, we noticed that exceptions thrown within the mapSelect function passed in the hook caused the same error but didn't include the stacktrace of the exception itself.

The reason for this is that the useSelect hook executes the mapSelect function in a try-catch block (reference), so exceptions are not reported upstream, only its side-effect in the shape of an undefined object and an error log in the RN console (reference).

This issue is making harder the task of debugging errors/crashes and it might be covering other potential issues, so it would be great to figure out a way to report them to Sentry.

To Reproduce

1. Add the following code throw Error( 'error test' ); into this line.
2. Open the app and connect it with the Metro server.
3. Open a post/page.
4. Tap on the ➕ button to open the inserter menu.
5. Observe that the error undefined is not an object is shown.
6. Observe in the RN console that the error An error occurred while running 'mapSelect': error test is logged.

Expected behavior
Exceptions thrown in the mapSelect function of useSelect hooks should be reported to Sentry.

Screenshots
N/A

Smartphone (please complete the following information):

• Device: iPhone 12 Pro Max
• OS: iOS 14.5
• Version 18.2

Additional context
N/A

[hypest]

👋 @nerrad and @ellatrix ! Looks like you worked on implementing this try/catch, any idea perhaps how to improve here? Goal is to be able to better capture where the error is happening so it'd be easier to spot from looking at crash logging tools like Sentry. Thanks!

[nerrad]

There's been a number of changes since I last worked on this and my memory is a bit fuzzy but from what I recall, originally the try/catch was added to work around some unique problems with a zombie/stale props issue due to the way React performs render calcs on children before parents (and thus any side-effects getting called in the children first). You can read more in the original conversation about how the try/catch helps to work around this.