Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

onUnhandledRejection missing from React Native #1816

Open
shamilovtim opened this issue Sep 16, 2022 · 2 comments
Open

onUnhandledRejection missing from React Native #1816

shamilovtim opened this issue Sep 16, 2022 · 2 comments
Labels
backlog We hope to fix this feature/bug in the future feature request Request for a new feature

Comments

@shamilovtim
Copy link

Description

Unhandled promises are warnings. They are not crashes or exceptions. Bugsnag is treating them like "unhandled exceptions" which affects our stability score and makes it inaccurate. We care that the app is crashing, not that Promises haven't resolved successfully.

Describe the solution you'd like

To make unhandled promises be considered "handled" exceptions we require the onUnhandledRejection callback. It is not available to us neither in the JS nor on the native platforms.

Describe alternatives you've considered

The API surface on React Native is too minimal and does not provide us with many options to accomplish this a different way.

Additional context

Please consider enlarging the React Native JS API. It does not have many options like the JS API does and leaves us having to make feature requests on this repo.

@luke-belton
Copy link
Member

Hi @shamilovtim - we mark uncaught promise rejections as unhandled in Bugsnag because the uncaught errors could potentially mask serious errors in your application code. We expose the onUnhandledRejection callback in Node because we replace the default process.on('unhandledRejection') handler, so have to mimic the default behaviour there.

That said, I'm going to pass your feedback onto our product team to see if there's anything we can do to make these types of error identifiable via a callback 👍

@luke-belton luke-belton added the needs discussion Requires internal analysis/discussion label Oct 4, 2022
@johnkiely1
Copy link
Member

Hi @shamilovtim, following some internal discussion we have added an item on the roadmap to expose the event type in a callback as way for you to achieve this. At the moment we don't have an ETA for this but we will keep you updated.

@johnkiely1 johnkiely1 added feature request Request for a new feature backlog We hope to fix this feature/bug in the future and removed needs discussion Requires internal analysis/discussion labels Oct 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backlog We hope to fix this feature/bug in the future feature request Request for a new feature
Projects
None yet
Development

No branches or pull requests

3 participants