W3C home > Mailing lists > Public > public-media-capture@w3.org > January 2014

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

From: Harald Alvestrand <harald@alvestrand.no>
Date: Wed, 08 Jan 2014 19:27:14 +0100
Message-ID: <52CD9882.9070907@alvestrand.no>
To: Jan-Ivar Bruaroey <jib@mozilla.com>, public-media-capture@w3.org
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 :.
Received on Wednesday, 8 January 2014 18:27:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:23 UTC