Re: MediaError object (Re: New Editor's draft v20131225)

On 1/8/14 12:28 AM, Harald Alvestrand wrote:
> DOMError is still unstable; we don't know what the end result of the 
> discussion between the DOM editor, the ECMA editor and the other 
> involved groups will be.
>
> So we decided that the prudent thing to do was to isolate the WebIDL 
> declaration of our error construct to our spec, noting in prose that 
> the intent is to be compatible with DOMError when it stabilizes.

OK, I must have missed that when we spent much of the teleconference 
call mapping DOMErrors to our APIs.

Do we mean compatible as in (err instanceof DOMError == true) 
eventually, or mere property equivalence?

> Experience from other contexts is that if people start down the path 
> of depending on the precise syntax of the "message" field, they'll 
> never stop ... which makes code prone to break in "interesting" ways.

If there's a use-case here other than "improving the error message shown 
to the user", for which I find message scanning totally reasonable, I'd 
like to hear it. If code depends on information in the error to 
determine what happens next, it may indicate a blind-spot in our design 
- Is it mandatory or isn't it?

> If someone needs to know the precise error .... the name and extra 
> parameters need to supply information enough.

Lets look at the design of the construct we proclaim to be using. 
DOMError covers all of DOM with 21 names without even a message-field (I 
hear they're adding one, bully for us), then we come along and add a 
third property we'll only use with one name, in half of one 
controversial API, for slippery slope reasons? That seems antithetical 
to the design to me, a DOMErrorino (DOMError in name only), except we 
wont have the actual name either.

I propose we drop the constraintName property unless use-cases can be 
shown that need it.

.: Jan-Ivar :.