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

On 01/07/2014 11:13 PM, Jan-Ivar Bruaroey wrote:
> Hi Dan, thanks for doing the update.
>
>
>> * Created a separate section on error handling.
>
> About:
>
> [NoInterfaceObject]
> interface MediaError {
>     readonly    attribute DOMString  name;
>     readonly    attribute DOMString? message;
>     readonly    attribute DOMString? constraintName;
> };
>
> Did we really decide to do this? I thought we were going with plain
> DOMError. How much should we warp the universe to make mandatory usable?
>
> Lets not add this. Firefox already gives you the name of the
> constraint that failed in the message, which is super-trivial to find
> in JS (and if not found, big deal. The end user gets a less than
> stellar error message, right? The call failed and it was mandatory, so
> there can't be another reason).

Breaking this into a separate thread:

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.

With regard to the separate constraintName: This has been this way for
half a year or so, I think (might be longer). 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 someone needs to
know the precise error .... the name and extra parameters need to supply
information enough.

I don't see a need to go back on this design.

(Note: I have some qualms about including constraintName in the
MediaError construct rather than in a subtype, since MediaError is used
in places not connected to constraints. The editors team concluded that
the extra complexity of an extra WebIDL type wasn't worth it. If this
matters to others, we might revisit the isue.)