Note regarding Proposal for issue #162: 'MediaStreamError should not be an interface'

Note: the definition of Errors is something we have been struggling 
with. Dan has now (after discussing with people) developed a proposal, 
see below.

The proposal was sent Tuesday this week, unless we hear objections by 
Tuesday next week we will ask the editors to incorporate the proposal in 
the Media Capture and Streams document.

Stefan for the chairs.


On 26/05/15 15:11, Dan Burnett wrote:
> I have been tasked with providing a proposal for how to proceed to address issue #162 [1].
>
> Based on a conversation among Domenic Denicola, Jan-Ivar, and others in PR #170 [2] (which was merely a draft of how to add a new error using ECMAScript 6-style language), I suggest the MediaStreamError defined in the Media Capture and Streams specification be removed and the errors in section 7.2 be addressed as follows.
>
> The following DOMException errors already defined in WebIDL will use their WebIDL names:
> - AbortError
> - NotSupportedError
> - NotFoundError
>
> The following errors that are new but semantically similar to existing error names will use those names, as suggested by Domenic Denicola in the above PR:
> - PermissionDeniedError will be replaced with the DOMException SecurityError
> - SourceUnavailableError will be replaced with the DOMException NotReadableError
>
> The two errors OverconstrainedError and ConstraintNotSatisfiedError will be combined into one new OverconstrainedError to be defined using EMCAScript 6-style language and include a new property 'constraint' to hold the name of a mandatory constraint that is overconstrained/not satisfied.  It is not possible to use WebIDL here (see the PR conversation), so the ES6 definition is the way we would need to proceed.
>
>
> Does anyone on the list have objections to this approach that they would like to discuss?  If not, I will write up the pull request making these changes.
>
> Any remaining events, if any, that could be generated based on the new set of errors (beyond the asynchronous returns already addressed by Promises) would require at least one additional pull request after this one to spec out.
>
> -- dan
>
> [1] https://github.com/w3c/mediacapture-main/issues/162
> [2] https://github.com/w3c/mediacapture-main/pull/170
>

Received on Friday, 29 May 2015 06:46:09 UTC