Exceptions from Promise constructor are always uncaught
Reported by
sadow...@a8c.com,
Jun 3 2016
|
||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36 Steps to reproduce the problem: 1. From the Sources tab of Developer Tools, enable "Pause on exceptions", but do not enable "Pause On Caught Exceptions" 2. Generate an exception. For example, attempt to register a service worker file from a different origin: window.navigator.serviceWorker.register( 'http://example.com/serviceworker.js' ).catch( function( err ) { console.log( 'Encountered Error', err ); } ); What is the expected behavior? I expect the exception to be caught, and that execution shouldn't be paused. What went wrong? The exception should be caught, the error should be logged to the console, and execution should continue as normal. Did this work before? No Chrome version: 50.0.2661.102 Channel: stable OS Version: OS X 10.11.4 Flash Version: Shockwave Flash 21.0 r0
,
Jun 4 2016
,
Sep 30 2016
I think it's more generic problem.
(new Promise(_ => { throw new Error(); })).catch(e => console.log(e))
And it looks like V8 issue because Promise.reject().catch(...) works fine.
I think that we'd like to get from V8 api promise rejected callback on exception in promise constructor instead of uncaught exception with good caught/uncaught prediction.
Dan, WDYT?
,
Sep 30 2016
If a Promise is rejected synchronously, before .catch is applied to it, I don't see any way that catch prediction could tell that .catch will be applied in the future and it should be predicted as caught. However, with async/await, if you await it enclosed in a catch block, I think this will correctly predict as caught. Additionally, if the Promise is rejected after somehow waiting asynchronously, it should predict as caught.
,
Dec 2 2016
I see. Sounds reasonable. Then it means that to make this exception caught - user can add try catch around register call.
,
Dec 2 2016
I don't see how the user would write their code with try/catch to make it predict as caught. However, if this is something that comes up a lot for people, I wonder if we could add a heuristic that looks for a literal ".catch" after a function call.
,
Dec 2 2016
That sounds way too ad-hoc to me. The .catch could refer to a completely unrelated Promise.
,
Dec 3 2016
Yes, it'd be really ad-hoc, but these are all fallible heuristics. The question in my mind is how big of a user experience hit is the current heuristic, which consistently fails in cases like this, and how often would the completely unrelated Promise case come up. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by dtapu...@chromium.org
, Jun 3 2016