RE: [Future] reject() value type

I think the less constraining approach is reasonable, although I question whether you'd need much extra beyond just a general agreement that all DOM specs use DOMError as their rejection reason. Stated another way, I think if you implemented the `Future<TValue, TReason>` idea, all DOM specs would just end up doing `Future<TValue, DOMError>`, which seems kind of pointless.

________________________________________
From: Mounir Lamouri [mounir@lamouri.fr]
Sent: Wednesday, May 08, 2013 13:49
To: www-dom@w3.org
Subject: [Future] reject() value type

Hi,

Currently, .resolve() and .reject() can pass any kind of value which
means that the callers will likely have to guess/know which value will
be given back to them.

When the Future is resolved, usually what is given back is pretty
obvious, it can be guessed from the context. It is also something that
is tested (hopefully) and should hopefully be advertised in the
specifications with this format: "Future<T>" [1].

However, when a Future is rejected, the returned value isn't as much
guessable, advertised or tested. It seems that Q promises use an Error
object [2] as a convention or restriction when .reject() is used. My
first thought was to use DOMError the same way they use Error but it
might make developers life harder.

A less constraining approach would be to ask the Future to establish
some kind of contract regarding the type of error it would return. It
would have to be done at different level.
First, a given method returning a Future should be required to always
return the same kind of error type. It could be an integer, a string, an
object but it shouldn't change depending on what happened. Otherwise,
developers might easily test their applications, have some code written
based on the errors they tried and, in production, a user might hit an
new type of error returning a different type of object and making
everything to fail.
Another requirement could be for new DOM APIs to use DOMError or
subclasses of DOMError as an error type.
Finally, as David Bruant suggested to me, I think it would be good to
advertise the error type in the IDL as much as the success type, like
"Future<Success, Error>", so developers don't have to guess what is
returned when an error occurs.

[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=21422
[2] https://github.com/kriskowal/q

--
Mounir

Received on Wednesday, 8 May 2013 17:53:52 UTC