You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are many faulty (android) native modules out there, that often threaten the stability of the whole app just by not properly handling (runtime) exceptions.
If RN would, by default, wrap each call to native modules exported functions in an exception handler and reject a promise in case an exception happens, then the overall stability of RN apps could improve.
Details
I recently had to deal with an increasing app crash rate in the Google play console. They all happened in one native module and all of them where unchecked runtime exceptions.
I could manually handle the exceptions and create patch for the module using patch-package. And then I wondered why isn't RN pro-actively protecting its calls into 3rd party modules from the JS side using an exception handler.
Introduction
There are many faulty (android) native modules out there, that often threaten the stability of the whole app just by not properly handling (runtime) exceptions.
If RN would, by default, wrap each call to native modules exported functions in an exception handler and reject a promise in case an exception happens, then the overall stability of RN apps could improve.
Details
I recently had to deal with an increasing app crash rate in the Google play console. They all happened in one native module and all of them where unchecked runtime exceptions.
I could manually handle the exceptions and create patch for the module using
patch-package
. And then I wondered why isn't RN pro-actively protecting its calls into 3rd party modules from the JS side using an exception handler.Discussion points
Maybe wrapping every call into an exception handler has speed impacts?
The text was updated successfully, but these errors were encountered: