Re: Fwd: [Bug 23367] Move exceptions into IDL

On 10/5/14, 4:28 AM, Harald Alvestrand wrote:
> On 10/04/2014 08:19 AM, Anne van Kesteren wrote:
>> # interface MediaStreamError  : Error
>>
>> Is not valid IDL. You can't mint your own exceptions. Only IDL is in
>> charge of exceptions.
>>
> Thus, I withdraw my proposal.
>
> Thanks for telling us about Yet Another Rule. If you can point at the
> part of the spec that says this, I'll be even happier; I missed that
> claim when reading the diff and the spec.

I agree with Harald the spec is misleading on this point, and it 
certainly confused me as well. The spec uses word like "inherit" [1], 
which combined with the promise-guide's use of SHOULD [2] rather than 
MUST, gives an idea of openness to inheritance. That this is not the 
case should be made more explicit. But moving on...

> So what's the proper form for saying "there exists an object that can
> turn up in the failure callback, and it may have a field called
> "constraint"?

The good news here is we're not alone. Encrypted Media Extensions [3] is 
another spec using promises (thanks Anne for pointing me to it) that 
also effectively needs a secondary field to DOMException [4]. A 
revelation of our similar needs could push things through. I think we 
should file a bug on DOMException for the secondary field, with urgency 
communicated. Since they've had plenty of time to consider the EME 
request, this seems doable to me.

Getting MediaStreamError promise-friendly seems an obstacle to last call 
whether we adopt promises out the gate or aim for polyfills later, so I 
think we need to address this before last call. This should be in 
everyone's interest.

.: Jan-Ivar :.

[1] http://w3ctag.github.io/promises-guide/#reasons-should-be-errors
[2] https://heycam.github.io/webidl/#es-exception-objects
[3] 
https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html

[4] The EME spec had until recently [5] a MediaKeyError with a secondary 
systemCode numeric attribute, much like our MediaStreamError with a 
secondary constraintName string attribute. These similar needs suggest 
that if DOMException wants to be the quintessential error for everybody, 
it at least needs an optional secondary field of malleable type. A (long 
or DOMString) secondaryArgument; should suffice as a stopgap that could 
potentially be extended with other types later.

[5] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25896

Received on Sunday, 5 October 2014 16:51:29 UTC