Be consistent with error handling

[henbos]

5.2 says to throw an InvalidAccessError if MediaTrackConstraints are used, 5.4 says deviceId can make it overconstrained which I think implies an OverconstrainedError is thrown, and I think other parts of the spec may have implied that unsupported constraints are simply ignored (no exception thrown), but I'm not sure about that last part.

• We should be consistent with how we handle errors. Should we use different exception types?
• If an unsupported constraint or a constraint that doesn't make sense, should we always throw an exception? If we throw on deviceId being set we might want to throw on other recognized attributes that aren't supported being set.

[henbos]

The "simply ignored" would be from section 5:

Though all constraints are supported for display device capture, not all constraints will have an effect.

[henbos]

Also contradiction: clearly not all constraints are supported if some of them throw an exception.

[henbos]

I'm trying to be consistent with getUserMedia().

With regards to InvalidAccessError at MediaTrackConstraints, this is throwing an exception because constraints were passed in that weren't applicable. I'm trying to figure out if getUserMedia() in this case would fail to satisfy the constraint because it was not applicable and hence throw an OverconstrainedError (if "exact" was used, but not if "ideal" was used?) or if it would silently ignore the constraint (as if a constraint unrecognized by WebIDL was passed in) and not throw an exception.
I filed w3c/mediacapture-main#533.

[henbos]

Is this covered by #73 ?

[jan-ivar]

@henbos Yes I think this is covered by #73, as it explicitly mentions never firing the overconstrained event. Can we close it?

I've opened specific issues on errors: #95 and #96.