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

On 01/08/2014 06:49 PM, Jan-Ivar Bruaroey wrote:
> 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?

property equivalence for certain. If DOMError gets stable before we 
publish, and nothing crappy happens, (err instanceof DOMError == true).

>
>> 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.

The constraintName property (and the sdpLineNumber property in the 
WebRTC draft) were added for reasons that seemed good at the time; you 
can't indicate a line number with an error code.

I'm fine with spinning that out in a special subtype, but I don't want 
to lose it.


>
> .: Jan-Ivar :.
>