W3C home > Mailing lists > Public > public-media-capture@w3.org > January 2013

RE: Move to de-facto error reporting

From: Jim Barnett <Jim.Barnett@genesyslab.com>
Date: Tue, 8 Jan 2013 18:29:42 +0000
To: Harald Alvestrand <harald@alvestrand.no>, Travis Leithead <travis.leithead@microsoft.com>
CC: "public-media-capture@w3.org" <public-media-capture@w3.org>, "public-webrtc@w3.org" <public-webrtc@w3.org>, "Adam Bergkvist (adam.bergkvist@ericsson.com)" <adam.bergkvist@ericsson.com>
Message-ID: <57A15FAF9E58F841B2B1651FFE16D28101310A@GENSJZMBX01.msg.int.genesyslab.com>
As I understand the proposal for point 1, the idea is to have an 'error' attribute in each class, whose value is significant only while an Error event is being processed.  (Thus we can all use the Error event class, and each class would  enum the legal values for the 'error' attribute). Our current class definitions define error events  with 'name' and 'detail' attributes, and I imagine that the 'detail' will be useful in some cases, so one question is where we would put that information.  Would we add an 'errorDetail' attribute to each class? (Its value would be an arbitrary string.)

- Jim

-----Original Message-----
From: Harald Alvestrand [mailto:harald@alvestrand.no] 
Sent: Tuesday, January 08, 2013 6:46 AM
To: Travis Leithead
Cc: public-media-capture@w3.org; public-webrtc@w3.org; Jim Barnett; Adam Bergkvist (adam.bergkvist@ericsson.com)
Subject: Re: Move to de-facto error reporting

Top-posting because it's a generic comment....

I see Travis making 2 almost unrelated points:

- Errors should be unified, we shouldn't invent new forms of error for each API.
- Errors should be events dispatched to an object representing the operation-in-progress, not callbacks.

I agree on the first one. I'm happy to accept any reasonable proposal for such an unification.

I disagree on the second one. This is another one of those "throw away all the users' code and tell them to start over" changes; we should only do that when there's a *clear* benefit to the users.

Disclosure: I did the first version of the stats API in the "new pattern" and switched to the "old pattern" for consistency across the PeerConnection API. I know it's possible to write both versions with equivalent functionality, because I've done it.

But I don't see an advantage to the "operation object" pattern that is compelling enough for us to tell the users to start over.

                Harald

On 12/20/2012 10:05 PM, Travis Leithead wrote:
> [Cross-posting for visibility]
>
> I'd like to suggest that we refactor our error handling behavior among all three WebRTC primary specs: WebRTC, Media Capture and Streams, and the Recording API. I'd like to move to the error model in use in DOM4/File API/IndexedDb and HTML5's Media Elements.
>
> I pointed out in another thread (http://lists.w3.org/Archives/Public/public-media-capture/2012Dec/0163.html) that the WebRTC/Media Capture/Recording API specs are using an error-notification model that is not based on the model being used by other specs in the WebApps and HTML working group-namely we're basing our model off of the Geolocation spec's pattern, rather than that of the DOM4/File API/IndexedDb/HTML5 pattern.
>
> The new pattern has only been around for a little over a year, so I don't think we can be blamed for not noticing/applying it earlier.
>
> To summarize the differences in the patterns:
> * The Geolocation pattern is to have a callback/event which is provided with an Error object which has a field which reports the name of the error (the error name and the exception names are usually the same).
> * The new pattern is to use a DOMError-based "error" attribute on the target object and use a normal vanilla "error" event to raise awareness that this state-attribute has been set.
>
> Here's how the Geolocation pattern plays out in the WebRTC, Media Capture and Streams, and Recording API proposals:
>
> An example from WebRTC's doc: RTCPeerConnection.createOffer says:
> void createOffer(RTCSessionDescriptionCallback successCallback,
>                   RTCPeerConnectionErrorCallback failureCallback, ...)
>
> Where RTCPeerConnectionErrorCallback will get an RTCError, and the RTCError has a "name" and a "message"
>
> This pattern is repeated elsewhere in getUserMedia: NavigatorUserMediaErrorCallback has a NavigatorUserMediaError with a "code".
> and now in the Recording Proposal [1]: onrecordingerror gets a RecordingError object which has a "name" and a "message"
>
> As you can see, this pattern needlessly complicates the web platform by having a bunch of objects that basically provide the exact same functionality.
>
> In the WebApps and HTML working groups, they have also seen this proliferation, and decided to unify under a new pattern for providing asynchronous error notifications. In the new pattern, there is an error state which is maintained by an object, and an event that fires to inform the application to check the object's error state.
>
> DOMError is the object that consolidates the functionality of RTCError, NavigatorUserMediaError, and RecordingError. It also consolidated similiarly proposed error objects in the File API, Indexed Db specs. The DOMError object is defined in DOM4 [2].
>
> Here's how it looks in FileReader [3]:
>
> interface FileReader {
>     readonly attribute DOMError error;
>              attribute Function? onerror;
>     ...
> }
>
> Here it is for Indexed Db transaction request objects [4]:
>
> interface IDBRequest {
>     readonly attribute DOMError error;
>              attribute Function? onerror;
>     ...
> }
>
> Here's how it's used in HTML5 [5] (which uses codes, unfortunately, so it's based on the model before DOMError came around, and has now been widely implemented so it can't be changed):
> Interface HTMLMediaElement {
>     readonly attribute MediaError? error;
>     ...
> }
> And an onerror handler defined in the super-interface HTMLElement.
>
> I'd like to propose that we re-use this concept for our specs. The specific changes would apply to:
>
> WebRTC spec:
> * RTCPeerConnection interface would get a DOMError error attribute, and an onerror EventHandler. The following APIs would need to be adjusted/simplified to remove the failureCallback parameter:
>    - createOffer
>    - createAnswer
>    - setLocalDescription
>    - setRemoteDescription
>    - getStats
>
> Media Capture and Streams spec:
> * MediaStream interface would get a DOMError error attribute, and an onerror EventHandler. The Following APIs would be adjusted to remove the errorCallback:
>    - getUserMedia
>
> Recording API spec:
> * MediaRecorder interface would get a DOMError error attribute. This interface already has an onrecordingerror handler, and it would be simplified to not carry the error state and behave like other normal event objects.
>
>
> [1] 
> http://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/RecordingP
> roposal.html [2] 
> http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#interface-dom
> error [3] http://dev.w3.org/2006/webapi/FileAPI/#dfn-error-codes
> [4] 
> http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#request-api
> [5] 
> http://www.w3.org/html/wg/drafts/html/master/embedded-content-0.html#m
> ediaerror
>
>
Received on Tuesday, 8 January 2013 18:30:09 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:03 GMT