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

Consider calling `window.onerror` on possibly unhandled rejections #428

Closed
benjamingr opened this Issue Jan 7, 2015 · 4 comments

Comments

Projects
None yet
3 participants
@benjamingr
Collaborator

benjamingr commented Jan 7, 2015

People often hook on window.onerror to log exceptions to the server. @domenic proposed native promises call window.onerror on unhandled rejections just like exceptions.

Pros:

  • Align with the proposed API for the web.
  • Bluebird remains a drop-in replacement for ES6 promises if the spec is approved with a more feature rich API.
  • Hook with tooling used to debug on the client.

Cons:

  • Promise.onPossiblyUnhandledRejection is already exposed allowing this, in the next version we might fire an event to process from all promises possibly rejected. It's already overridable.
  • API is not approved yet.
  • Add complexity to the library and more browser/node specific logic.
  • We have observed people treat onPossiblyUnhandledRejection in many different ways, some suppress it, some make it throw and some make it perform custom logic. This indicates not everyone treats these as errors.

I'm not aware of any other promise libraries considering this at the moment.

@petkaantonov

This comment has been minimized.

Show comment
Hide comment
@petkaantonov

petkaantonov Jan 7, 2015

Owner

I am not sure a separate issue is needed, whatever events we do on process in node will be done on window in browser. However, onerror is bad because we won't be using the equivalent in node (onUncaughtException) and its signature is very different.

Owner

petkaantonov commented Jan 7, 2015

I am not sure a separate issue is needed, whatever events we do on process in node will be done on window in browser. However, onerror is bad because we won't be using the equivalent in node (onUncaughtException) and its signature is very different.

@benjamingr

This comment has been minimized.

Show comment
Hide comment
@benjamingr

benjamingr Jan 7, 2015

Collaborator

@petkaantonov I tend to agree withthat. To be fair I don't understnad why Domenic would even want this behavior.

Collaborator

benjamingr commented Jan 7, 2015

@petkaantonov I tend to agree withthat. To be fair I don't understnad why Domenic would even want this behavior.

@domenic

This comment has been minimized.

Show comment
Hide comment
@domenic

domenic Jan 7, 2015

It's not me that wants it; it's the other Chrome engineers :(

domenic commented Jan 7, 2015

It's not me that wants it; it's the other Chrome engineers :(

@benjamingr

This comment has been minimized.

Show comment
Hide comment
@benjamingr

benjamingr Jan 7, 2015

Collaborator

@domenic calling onerror nondeterministically really didn't sound like you :)

Collaborator

benjamingr commented Jan 7, 2015

@domenic calling onerror nondeterministically really didn't sound like you :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment