This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html Multipage: http://www.whatwg.org/C#images Complete: http://www.whatwg.org/c#images Referrer: http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=13&ved=0CDoQFjACOAo&url=http%3A%2F%2Fwww.whatwg.org%2Fspecs%2Fweb-apps%2Fcurrent-work%2Fmultipage%2Ftimers.html&ei=Xg1xU7ymIsmvyATkioK4Cw&usg=AFQjCNF2Xnrwgun2m7KcyqkqLsqEvc8LYQ&sig2=DubxYrOGGBzkcQ2wIFEwRA&bvm=bv.66330100,d.aWw Comment: Promise usage review: - Can use Promise<ImageBitmap> WebIDL syntax for better documentation - All the "throw an exception" steps will be automatically fixed by WebIDL to become rejected promises, but you could make it clearer to the reader by saying "return a promise rejected with an IndexSizeError exception" instead of "throw an IndexSizeError exception." - "Fulfill the Promise's associated resolver with ... as the value" should become "resolve the promise with ..." - There is no need to perform steps asynchronously if there is no off-main thread work going on. E.g. many cases do no actual work, but just resolve the promise with a new ImageBitmap. There is no need to do those in a separate set of async steps after the main algorithm returns. - Relatedly, it seems like there is some heavy processing going on that is not being done asynchronously, e.g. cropping and so on. Shouldn't those steps be done async? Code example: change Promise.every(...) to Promise.all([...]) The constructor parameter changed slightly. The new version should be: var resolve; new Promise(function (arg) { resolve = arg; }); resolve(Promise.all([...])) Posted from: 12.173.83.50 User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:29.0) Gecko/20100101 Firefox/29.0
Why can't I throw an exception from this method? Separate from rejecting the promise later, I mean, which would happen if there was some unexpected problem rather than one that can be statically and synchronously detected when the method is invoked and indicates an authoring error.
Forcing users to include two ways of detecting exceptions from your methods is bad. Then they have to do ```js try { asyncThing().catch(handleError); } catch (e) { handleError(e); } function handleError(e) { // recover and continue } ``` instead of ```js asyncThing().catch(e => { // recover and continue }); ``` Previous discussion at https://github.com/domenic/promises-unwrapping/issues/24
I don't think these exceptions are exceptions that you'd normally ever want to catch. The problem is that I don't want these exceptions to get mixed in with the "expected" exceptions that are things like "this file isn't a valid image". Back when this API used callbacks, the distinction would have been that bad arguments would throw synchronously, while bad data (something that might happen even if the script has no logic errors) would result in the callback being invoked with "null" as the result, or some such.
Ok, I give up. It's a lame language design decision, but it's time for me to move on. Here's my game plan: 1. Update the IDL to use Promise<ImageBitmap>. 2. Use "return a promise rejected with an [...] exception" where I use "throw" currently. 3. "Fulfill the Promise's associated resolver with ... as the value" should become "resolve the promise with ..." or whatever WebIDL defines. 4. Change Promise.every(...) to Promise.all([...]) in the example. 5. Change resolver.resolve() to just resolver() in the example.
Checked in as WHATWG revision r8804. Check-in comment: Integrate with new promise stuff better https://html5.org/tools/web-apps-tracker?from=8803&to=8804