We should find a more general approach (ideally driven by the binding generator templates) to throw uncaught exceptions when JS callbacks dispatched on the event loop from C++, throws. We're currently wrapping some of our listener APIs in a pattern that catch errors from callback and use setImmediate to rethrow from a new task scheduled from JS, but we have many callbacks that doesn't have this manual "workaround".
We should find a more general approach (ideally driven by the binding generator templates) to throw uncaught exceptions when JS callbacks dispatched on the event loop from C++, throws. We're currently wrapping some of our listener APIs in a pattern that catch errors from callback and use
setImmediate
to rethrow from a new task scheduled from JS, but we have many callbacks that doesn't have this manual "workaround".I've pushed https://github.com/realm/realm-js/tree/kh/fix-throwing-callbacks as a starting point, disabling the workaround and adding a few failing tests that are now causing aborts.
My current thinking is that we should implement platform specific "EventLoopDispatchers" wrapping Core's
util::EventLoopDispatcher
used here: https://github.com/realm/realm-js/blob/f8aefa20ebd03a9178b79ea8fa0ed72bf206696e/packages/realm/bindgen/src/templates/node.ts#L588 or arealm::util::Scheduler
and set this as "default" the way I did in #6791. The platform dispatcher should wrap the lambda with a try-catch which reports the error as an uncaught exception using platform specific runtime APIs.