{"action":"created","issue":{"url":"https://api.github.com/repos/nodejs/promises/issues/26","repository_url":"https://api.github.com/repos/nodejs/promises","labels_url":"https://api.github.com/repos/nodejs/promises/issues/26/labels{/name}","comments_url":"https://api.github.com/repos/nodejs/promises/issues/26/comments","events_url":"https://api.github.com/repos/nodejs/promises/issues/26/events","html_url":"https://github.com/nodejs/promises/issues/26","id":136188250,"number":26,"title":"Default Unhandled Rejection Behavior","user":{"login":"benjamingr","id":1315533,"avatar_url":"https://avatars.githubusercontent.com/u/1315533?v=3","gravatar_id":"","url":"https://api.github.com/users/benjamingr","html_url":"https://github.com/benjamingr","followers_url":"https://api.github.com/users/benjamingr/followers","following_url":"https://api.github.com/users/benjamingr/following{/other_user}","gists_url":"https://api.github.com/users/benjamingr/gists{/gist_id}","starred_url":"https://api.github.com/users/benjamingr/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/benjamingr/subscriptions","organizations_url":"https://api.github.com/users/benjamingr/orgs","repos_url":"https://api.github.com/users/benjamingr/repos","events_url":"https://api.github.com/users/benjamingr/events{/privacy}","received_events_url":"https://api.github.com/users/benjamingr/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":63,"created_at":"2016-02-24T21:15:28Z","updated_at":"2016-09-12T20:49:57Z","closed_at":"2016-09-09T23:01:04Z","body":"Continuation of https://github.com/nodejs/node/issues/830\r\n\r\nAfter a few months of `process.on(\"unhandledRejection\"` event I'm convinced we need a saner default.\r\n\r\nJust 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. Basically - anything that fires\r\n\r\n**The different approaches**\r\n-------\r\n - **Throwing an error for `process.on(\"uncaughtException\"` to deal with.** - this seems impractical now since the hook has been live in the ecosystem for a while. A flag might solve this.\r\n - **Causing the process to exit.** - this seems impractical now since the hook has been live in the ecosystem for a while. A flag might solve this.\r\n - **Do nothing by default.** - what we currently do - a lot of complaints about this.\r\n - **Logging the rejection to the console.** - this is what most browsers do now (namely Chrome) and what bluebird and userland libraries do. I think we should explore that path.\r\n\r\n## Proposal\r\n\r\nWhen an `unhandledRejection` event is fired if no handlers are attached the error is logged to stderr. The current behavior is confusing to users and makes it appear as if promises swallow errors. While the `unhandledRejection` hook has been used a lot in the wild a lot of users (even experienced node users) can forget it and get surprising behavior.\r\n\r\nPeople will still be able to opt-out of it by installing any `\"unhandledRejection\"` handler. \r\n\r\nThis aligns Node's behavior with browsers and other environments as well as userland solutions."},"comment":{"url":"https://api.github.com/repos/nodejs/promises/issues/comments/246488307","html_url":"https://github.com/nodejs/promises/issues/26#issuecomment-246488307","issue_url":"https://api.github.com/repos/nodejs/promises/issues/26","id":246488307,"user":{"login":"bmeck","id":234659,"avatar_url":"https://avatars.githubusercontent.com/u/234659?v=3","gravatar_id":"","url":"https://api.github.com/users/bmeck","html_url":"https://github.com/bmeck","followers_url":"https://api.github.com/users/bmeck/followers","following_url":"https://api.github.com/users/bmeck/following{/other_user}","gists_url":"https://api.github.com/users/bmeck/gists{/gist_id}","starred_url":"https://api.github.com/users/bmeck/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/bmeck/subscriptions","organizations_url":"https://api.github.com/users/bmeck/orgs","repos_url":"https://api.github.com/users/bmeck/repos","events_url":"https://api.github.com/users/bmeck/events{/privacy}","received_events_url":"https://api.github.com/users/bmeck/received_events","type":"User","site_admin":false},"created_at":"2016-09-12T20:49:57Z","updated_at":"2016-09-12T20:49:57Z","body":"@ljharb the abrupt completion handling is at [PromiseReactionJob](https://tc39.github.io/ecma262/#sec-promisereactionjob) and [RunJobs](https://tc39.github.io/ecma262/#sec-runjobs). When using [HostReportErrors](https://tc39.github.io/ecma262/#sec-host-report-errors) the operation *must* complete normally (assuming it can complete). If we `abort` on GC I don't see a violation unless I am mistaken."}}
{"actor":{"display_login":"bmeck"}}