- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Wed, 22 Apr 2015 10:42:15 +0200
- To: Dan Burnett <dburnett@voxeo.com>
- CC: WebRTC-Editors <webrtc-editors@alvestrand.no>, public-webrtc-editors@w3.org
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. 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.
Received on Wednesday, 22 April 2015 08:42:44 UTC