W3C home > Mailing lists > Public > public-media-capture@w3.org > December 2012

defining consistent error handling

From: Jim Barnett <Jim.Barnett@genesyslab.com>
Date: Tue, 11 Dec 2012 18:37:23 +0000
To: "public-media-capture@w3.org" <public-media-capture@w3.org>
Message-ID: <57A15FAF9E58F841B2B1651FFE16D281E456@GENSJZMBX01.msg.int.genesyslab.com>
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.


-          Jim
Received on Tuesday, 11 December 2012 18:37:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:13 UTC