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 04:24:34 -0400
Cc: WebRTC-Editors <webrtc-editors@alvestrand.no>, public-webrtc-editors@w3.org
Message-Id: <0E2B4F3F-944E-4FEC-AE49-3C345CA5C8F5@voxeo.com>
To: Harald Alvestrand <harald@alvestrand.no>

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.

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?
Received on Wednesday, 22 April 2015 08:25:03 UTC

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