- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Tue, 7 Oct 2014 16:25:51 -0700
- To: Harald Alvestrand <harald@alvestrand.no>
- Cc: Adam Bergkvist <adam.bergkvist@ericsson.com>, "public-media-capture@w3.org" <public-media-capture@w3.org>
On 7 October 2014 15:35, Harald Alvestrand <harald@alvestrand.no> wrote:
> navigator.getUserMedia = function(constraints, successCallback,
> failureCallback) {
> let result = navigator.mediaDevices.getUserMedia(constraints);
> result.then(successCallback, failureCallback);
> return result;
> }
>
> This removes successCallback and failureCallback from the promise
> chain, but it also ensures that you don't get any weird problems when
> the callbacks return promises, or throw exceptions.
>
> OK, the difference between this and the original proposal on the thread is
> that you return the promise, which makes the function fall under the special
> rules for promise-returning functions. (or does it? This is Javascript, not
> WebIDL).
>
> So it's subtly different from the pre-Promise specification, but callers who
> throw away the promise won't notice.
>
> What weird behaviours are prevented by this change?
[whoa, bold text overload]
What I neglected to mention is that exceptions (such as they are) are
caught by the promise rather than being thrown directly. That's going
to affect sites who do argument type checking and rely on that
surfacing in a try { gUM(); } catch(e) { }. This sort of this is
usually programming error (rather than runtime error), so I'd expect
the impact to be low.
Received on Tuesday, 7 October 2014 23:26:19 UTC