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

Even better news: It seems that the Promises spec doesn't really 
constrain what the failure parameter is, so we can just keep on using 
our own error definition until this is sorted out.



Den 05. okt. 2014 18:51, skrev Jan-Ivar Bruaroey:
> 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 Monday, 6 October 2014 07:20:11 UTC