[whatwg] Web Notification: API inconsistency

Boris Zbarsky bzbarsky at MIT.EDU
Fri Aug 23 10:41:15 PDT 2013

On 8/23/13 1:23 PM, Tab Atkins Jr. wrote:
> On Fri, Aug 23, 2013 at 10:22 AM, Anne van Kesteren <annevk at annevk.nl> wrote:
>> On Fri, Aug 23, 2013 at 6:09 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
>>> If we want to continue returning void when a callback is passed, we need to
>>> add some webidl magic for that...
>> My idea was to always return a promise. And if a callback is passed
>> you just pass that to the promise "as listener".
> Yeah, we can just auto-add the callback as a .then() argument on the
> returned promise.  Maybe then return the promise returned by .then(),
> rather than the original?

Given the last definition of then() I saw, this has a bit of a gotcha. 
Consider this code:

   function callback() {
     throw "Hey"

now in today's world, when some API calls back into callback an 
exception is reported to the console and window.error and whatnot.

But if someAPI internally does:

   var promise = new Promise();
   return promise.then(callback);

then all throwing from callback will do is set up the error state on the 
return value; the exception is not reported anywhere.

Now UAs might end up reporting to the console when a promise with an 
unhandled error is GCed or something.  But window.onerror is SOL in this 


More information about the whatwg mailing list