Re: defining consistent error handling

On 2012-12-11 19:37, Jim Barnett wrote:
> Section 4.6 of the webRTC spec is pretty specific about error handling
> (http://dev.w3.org/2011/webrtc/editor/webrtc.html#error-handling) .  It
> defines an interface RTCError with attributes ‘name’ and ‘message’.  It
> then says that an exception must be raised if the args to an API call
> are the wrong type or if the system is in the wrong state.  Otherwise an
> error must be raised.  In both cases the RTCError interface is used.
> The section provides separate enums for the ‘name’ attribute to be used
> for exceptions and errors.
>
> The media capture spec is not consistent with this.  It twice mentions
> ‘wrong state’ exceptions but doesn’t define them any further.  It does
> define a NavigatorUserMediaError, but it’s only attribute is ‘code’.
>
> I think that it would make sense to align the error treatment in the two
> specs.  We can probably copy section 4.6 directly into gUM, changing the
> error interface to “MCError” or “gUMError” or something like that, and
> defining our own enums. We should also add more detail on the exceptions.
>
> The recording spec can then either have another copy of the  language
> (with its own interface name and enums) or it can reference the language
> in gUM.  I prefer the latter because then we don’t have to worry about
> the language getting out of synch.

I agree that it would be preferable to have consistent error handling 
behavior between the specs.

But before copying (if that's what we decide to do) anything we should 
make sure that we're fairly happy with the text to avoid extra work. 
I'll start a thread in public-webrtc to address what I consider being 
redundant spec text in Section 4.6.

/Adam

Received on Wednesday, 12 December 2012 07:17:54 UTC