[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"
}
someAPI(callback);
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
case.
-Boris
More information about the whatwg
mailing list