W3C home > Mailing lists > Public > public-script-coord@w3.org > January to March 2014

[Bug 25048] consider whether an IDL attribute of type Promise<T> should catch exceptions and wrap them up as a rejected Promise like they are for operations

From: <bugzilla@jessica.w3.org>
Date: Fri, 14 Mar 2014 02:34:27 +0000
To: public-script-coord@w3.org
Message-ID: <bug-25048-3890-xz3Cne1rUp@http.www.w3.org/Bugs/Public/>

--- Comment #5 from Domenic Denicola <domenic@domenicdenicola.com> ---
> Or to put this another way: are there any use cases for allowing attributes of Promise type at all?

For sure! See all the usage in [1] or [2]. Or, the recently-proposed
loaded/ready promises could easily be attributes, if not for the fact that most
of those resources allow you to reload them (e.g. by setting `.src` again).

> The most common practical source of exceptions is if you .call() the getter function on a wrong kind of object.

This should return a rejected promise for the same reason; if you are using a
getter representing an asynchronous result, you should expect to be able to do
asynchronous error handling.

> Hmm, what if you had an IDL attribute of a Promise<T> type that throws when assigning?

Yeah, this is trickier to reason about---mainly because I don't know of a
reasonable use case for promise attributes with setters. I assume there'd be
coercion behavior, so e.g. for a Promise<long> attribute these would be fine:

foo.bar = 5;
foo.bar = Promise.resolve(5);

but these would not:

foo.bar = {};
foo.bar = Promise.resolve(function () { });

I would probably again argue that the result should be `foo.bar` set to a
promise rejected with a `TypeError`, since people would access the result of
the set via

foo.bar.then(processValueRepresentedByBar, couldNotGetValue);

and would be surprised if they had to write

try {
  foo.bar.then(getValueThatWasSet, couldNotGetValue);
} catch (e) {

[1]: https://github.com/whatwg/streams

You are receiving this mail because:
You are on the CC list for the bug.
Received on Friday, 14 March 2014 02:34:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:19 UTC