Re: Error types (Re: Notes, April 16)

On Apr 22, 2015, at 4:42 AM, Harald Alvestrand wrote:

> Den 22. april 2015 10:24, skrev Dan Burnett:
>> 
>> On Apr 22, 2015, at 2:43 AM, Harald Alvestrand wrote:
>> 
>>> Den 21. april 2015 21:42, skrev Dan Burnett:
>>>>>> #140 declaration for error type: Dan - need to make sure we have
>>>>>> consistent errors.
>>>> Not sure how I got assigned this fun one, but I guess that's what I get for having to drop off 10 mins early :)  This is now looking like a more comprehensive change, in both specs perhaps.
>>>> 
>>> 
>>> We have a bug (from Anne I believe) to make sure we do the right thing
>>> on getusermedia wrt errors. Our stance of "we declare what we want to
>>> have, and wait for the webidl / ecmascript landscape to stop moving"
>>> seems to have been the right one.
>>> 
>> 
>> Yes, that's what I was referring to.  In the case of the gUM spec it's a single new Error "subclass", but for the WebRTC spec we currently have several:
>> - RTCSDPError
>> - RTCIdentityError (possibly modified to differentiate idpassertionerror from idpvalidationerror)
>> - possibly a new RTCIceCandidateError for the TBDs there
>> - InvalidSessionDescriptionError, IncompatibleSessionDescriptionError, IncompatibleConstraintsError, and InternalError.  Any of these we keep would need RTC prefixes.
>> 
> 
> I'm hoping that we can get away with:
> 
> - A very small number of new Error "subclasses" for the cases where we
> need to add extra information to the error. Some people seem to dislike
> these intensely, but I do think we have to have them.
> 
> - A somewhat larger number of new Error *name* values, where we add no
> new information. There seems to be much smaller resistance to that.

I also had the same hope.  As you mention below, though, an error's name is its type/class, and the only variable piece is the user-readable message.  We will need one or more new error-like *things*, each of which not only has a distinct name/type/class and a user-readable message, but also code-readable property value(s).  Identifying the minimal set is the challenge.

> 
> The ECMAScript 6 spec seems to mix these two concepts together somehow,
> with language that sounds like "the name always reflects the name of the
> class". That sounds like a weird way to do things, especially when using
> prose not markup for the definition, but if we have to, we have to.
> 
>> At this point I'm thinking I should
>> - email the Media Cap list with a pointer to Domenic's suggestion for MediaStreamError as a sanity check on the approach of defining custom Error subclasses as Domenic describes.  The change itself can then be a pull request before it goes in.
>> - provide the list of new Error subclasses I think we need for WebRTC on the webrtc list, with a ref to the Media Cap email as an example of how it can be done.  Assuming there is general agreement on the list, I (and/or others) can then create one or more PRs for the changes that can be reviewed before they go in.
>> 
>> Thoughts?
> 
> Seems like a plan. Domenic needs to be in the loop to make sure we
> understood him correctly, of course.

Absolutely.  This is one of the reasons the discussion will need to happen on the list, with Domenic as an explicit addition.

> 
>

Received on Wednesday, 22 April 2015 13:56:12 UTC