Re: [mediacapture-main] rough draft of new PermissionDeniedError object

On 05/21/2015 05:17 PM, Domenic Denicola wrote:
>
>     @domenic <https://github.com/domenic> , we have a need to give
>     back errors that allow Javascript to take different decisions
>     based on something predictable
>
> Profuse apologies since I am probably retreading old ground, but can
> you explain why this is? (I.e. the user-facing use case---different 
UI
> that will be shown, for example.)
>

The typical example (and one that consumes one of our errors) is the
difference between "no such device" and "permission denied".
In this case, the JS need is to say "please plug in a camera" versus
"OK, if you don't want to make a call, let's not do it".

> In contrast, JS does not include a way to distinguish between the
> TypeError caused by trying to call a non-function and the TypeError
> caused by trying to access a property of |null|. DOM does not allow
> distinction between the InvalidStateError DOMException caused by
> dispatching an event twice and that caused by using 
surroundContents()
> incorrectly. Etc.
>
In the case of a TypeError, one can (theoretically) inspect the object
and figure out what caused the error. In the case of a getUserMedia
call, all that is returned in an error case is the error; the state 
that
caused the error is not made available for inspection.

> If there are such use cases, then perhaps separate errors are the 
way
> to go; the alternative would be introducing a property like |type| 
or
> |cause| that takes a string enum, but that might be a bit too 
ad-hoc.
> (At one time I outlined vague hopes
> <https://esdiscuss.org/topic/error-objects-in-w3c-apis#content-4> 
for
> something more comprehensive, but I wouldn't want to make you guys 
the
> guinea pigs for such a scheme.)
>
> But it's unclear to me why MSE is special such that unlike other web
> specs there's a need to distinguish.
>

I think the cases in the document where new error codes are used, the
state is relatively clear.

We *also* have the issue of returning additional information (such as
the constraint that was unsatisfiable in the constraint error case),
which the WG has idnicated that it strongly wants.
Assuring that the extra information is available has traditionally 
been
the role of the type system, which means that extra types seems like 
the
way to go, no matter how the other issue resolves.



-- 
GitHub Notif of comment by alvestrand
See 
https://github.com/w3c/mediacapture-main/pull/170#issuecomment-104345783

Received on Thursday, 21 May 2015 16:32:16 UTC