W3C home > Mailing lists > Public > public-webrtc-editors@w3.org > April 2015

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

From: Dan Burnett <dburnett@voxeo.com>
Date: Wed, 22 Apr 2015 09:55:41 -0400
Cc: WebRTC-Editors <webrtc-editors@alvestrand.no>, public-webrtc-editors@w3.org
Message-Id: <07D62D0C-7BEE-4A12-81FB-1C254C6EB1C9@voxeo.com>
To: Harald Alvestrand <harald@alvestrand.no>

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:19:02 UTC