{"action":"created","issue":{"url":"https://api.github.com/repos/nodejs/node/issues/830","labels_url":"https://api.github.com/repos/nodejs/node/issues/830/labels{/name}","comments_url":"https://api.github.com/repos/nodejs/node/issues/830/comments","events_url":"https://api.github.com/repos/nodejs/node/issues/830/events","html_url":"https://github.com/nodejs/node/issues/830","id":57588499,"number":830,"title":"Default Unhandled Rejection Detection 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":[{"url":"https://api.github.com/repos/nodejs/node/labels/discuss","name":"discuss","color":"02d7e1"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":112,"created_at":"2015-02-13T11:31:38Z","updated_at":"2015-11-12T16:36:21Z","closed_at":null,"body":"With https://github.com/iojs/io.js/pull/758/ (hopefully) soon landing to address https://github.com/iojs/io.js/issues/256 we will soon have unhandled promise rejections reported to the process via a `process.on(\"unhandledRejection\"` event. \r\n\r\nOne issue that was deliberately deferred from that issue and PR is what the default behaviour of an unhandled promise rejection detected be.\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.\r\n\r\n**The different approaches**\r\n-------\r\n - Logging the rejection to the console.\r\n - Throwing an error for `process.on(\"uncaughtException\"` to deal with.\r\n - Causing the process to exit.\r\n - Do nothing by default.\r\n\r\nThere 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.\r\n\r\n### Logging\r\n - No silent failure by default.\r\n - Does not break any existing code - no \"surprises\". (See comment by @vkurchatkin on this)\r\n - Been a default in several userland libraries like bluebird and users have been very satisfied with it.\r\n\r\n### Throwing an error\r\n - A promise rejection is the asynchronous version of a thrown exception.\r\n - Does not ignore logical errors or leave the app in an inconsistent state. \r\n - 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.\r\n\r\n### Process Exit\r\n - Differentiation between uncaught exceptions and promise rejections might be useful.\r\n\r\n### Do nothing\r\n - 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. \r\n - Does not break any existing workflows for anyone. No backwards compatibility issues for native promise users at all.\r\n - Does not make any assumptions on how people use native promises.\r\n\r\n------------\r\n\r\nWhat do people think the default behaviour should be?"},"comment":{"url":"https://api.github.com/repos/nodejs/node/issues/comments/156158892","html_url":"https://github.com/nodejs/node/issues/830#issuecomment-156158892","issue_url":"https://api.github.com/repos/nodejs/node/issues/830","id":156158892,"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},"created_at":"2015-11-12T16:36:20Z","updated_at":"2015-11-12T16:36:20Z","body":"@Zoltu that's not what C# does at all. C# has a concept of an execution context - for example ASP.NET will _fail the request_ even if there are _no unhandled rejections_ just because  there are async in flight actions created in the request context and not resolved by the time you're sending the response. \r\n\r\n\r\nAside from that: \r\n\r\nI'm 100% with @mikeal here, I have another suggestion: we wait for the TC to finish the official promise hooks, wait to see what browsers implement and _in a year_ we go with _whatever behavior browsers have settled on by then_ since that will be _de facto standard_.\r\n\r\n"}}