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

(this is a resend after failing to reply from my phone. Apologies if it 
appears twice)

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 :.

On 10/7/14, 7:25 PM, Martin Thomson wrote:
> 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 01:57:12 UTC