Skip to content

Default Unhandled Rejection Detection Behavior #830

Closed
@benjamingr

Description

@benjamingr

With #758 (hopefully) soon landing to address #256 we will soon have unhandled promise rejections reported to the process via a process.on("unhandledRejection" event.

One issue that was deliberately deferred from that issue and PR is what the default behaviour of an unhandled promise rejection detected be.

Just to be clear - this is about the default behaviour of a rejected promise with no catch handler (or then handler with a function second argument) attached.

The different approaches

  • Logging the rejection to the console.
  • Throwing an error for process.on("uncaughtException" to deal with.
  • Causing the process to exit.
  • Do nothing by default.

There are several good arguments for each approach. I'll write down the arguments I'm aware of and will edit arguments as people make them in comments.

Logging

  • No silent failure by default.
  • Does not break any existing code - no "surprises". (See comment by @vkurchatkin on this)
  • Been a default in several userland libraries like bluebird and users have been very satisfied with it.

Throwing an error

  • A promise rejection is the asynchronous version of a thrown exception.
  • Does not ignore logical errors or leave the app in an inconsistent state.
  • False positives are extremely rare - and code causing them can arguably easily be refactored to not cause them by not attaching error handlers too late.

Process Exit

  • Differentiation between uncaught exceptions and promise rejections might be useful.

Do nothing

  • Reliable promise rejection detection is non-deciable, it's possible to report an unhandled rejection that actually is handled at a later point if the catch handler is attached at a very late time.
  • Does not break any existing workflows for anyone. No backwards compatibility issues for native promise users at all.
  • Does not make any assumptions on how people use native promises.

What do people think the default behaviour should be?

Metadata

Metadata

Assignees

No one assigned

    Labels

    discussIssues opened for discussions and feedbacks.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions