RE: Strawman Promises consensus position, based on Thursday's telechat

Right, so you don't want to return a promise here I don't think, as the goal is to preserve the old behavior - throw on bad args. (this is webidl not JavaScript as the pull request makes clear).

As for any exceptions thrown in the actual callbacks, this would be the first time the spec has given them any thought I think. I believe Firefox currently logs them to the web console.

I suppose we could specify that it should do the equivalent of navigator.mediaDevices.getUserMedia(constraints).then(success, failure).catch(logToWebConsole), but I'm not sure how to write that since we haven't mentioned how to handle exceptions before.

.: Jan-Ivar :.

-------- Original message --------
From: Martin Thomson <martin.thomson@gmail.com> 
Date:10/07/2014  7:27 PM  (GMT-05:00) 
To: Harald Alvestrand <harald@alvestrand.no> 
Cc: Adam Bergkvist <adam.bergkvist@ericsson.com>,public-media-capture@w3.org 
Subject: Re: Strawman Promises consensus position, based on Thursday's telechat 

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 Wednesday, 8 October 2014 08:12:03 UTC