W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2013

Re: [whatwg] Web Notification: API inconsistency

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Fri, 23 Aug 2013 13:41:15 -0400
Message-ID: <52179EBB.9070106@mit.edu>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: WHATWG <whatwg@lists.whatwg.org>
On 8/23/13 1:23 PM, Tab Atkins Jr. wrote:
> On Fri, Aug 23, 2013 at 10:22 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
>> On Fri, Aug 23, 2013 at 6:09 PM, Boris Zbarsky <bzbarsky@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 

Received on Friday, 23 August 2013 17:41:43 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:23 UTC