Re: Dictionary-shaped Hammers

Hi Jan-Ivar,

On 12/12/2013 4:07 PM, Jan-Ivar Bruaroey wrote:
> FWIW it is not the case that there wont be exceptions. The spec is 
> expressed largely in WebIDL, which implies lots of argument 
> validity-checking and type-checking using exceptions. Try passing a 
> number in place of a required object argument for instance, or (as I 
> pointed out already) a facingMode constraint you never heard of, 
> mandatory or optional.
>
> I opened with saying I'm opposed to fail-always on unknown mandatory 
> constraints, but if we want that behavior, then arguably, treating an 
> unknown-to-the-UA object-property as a type-error doesn't seem totally 
> unreasonable to me. After all, the app is trying to use a feature the 
> browser doesn't understand. This would be a way to get the fail-always 
> behavior others here desire and still use dictionaries. It is a 
> compromise.
>
> I like that this at least differentiates between "the browser cannot 
> tell" and "the camera for-sure does not have the feature", which are 
> not the same thing, and something we seem to conflate whenever we talk 
> about this (ignoring the false-negative problem's existence).
>
> As to promises, I believe they handle exceptions. From 
> http://blog.parse.com/2013/01/29/whats-so-great-about-javascript-promises 
> :
>  "Generally, developers consider a failing promise to be the 
> asynchronous equivalent to throwing an exception. In fact, if a 
> callback passed to 'then' throws an error, the promise returned will 
> fail with that error."

I think we're actually in agreement here. I'm not against the use of 
exceptions (in fact, I favor them over the use of error codes). I simply 
meant that I expected all results (success/error) to come from the 
callback as opposed to being returned from getUserMedia() synchronously.

Gili

Received on Thursday, 12 December 2013 22:10:04 UTC