RE: making progress on error handling

>> On the other hand, if we go the route of allowing apps to build dummy tracks and assign them properties, so that they can be used for negotiation, we have to deal with the errors that can arise when the track is connected to a source device that lacks the specified property.  This is really the same sort of error as the failure of a mandatory constraint.  Do we again want to use "permission denied" for this case?

I'll call this:

*         constraint failures (e.g., you pre-established some constraints [or requested that they be changed dynamically], and when it came time to hookup a source [or change a source], the source couldn't satisfy the constraint(s)

I'm not sure if I need constraint warnings-I can't think of a reason when this would occur that isn't caught early when evaluating the structure of a constraint object (which would result in exceptions, not async errors).

I definitely need a notice of some form when source state information changes ("width" / "height"), but that's not in the realm of errors.

For the constraint failures themselves, I'm fuzzy on the granularity of what to report. In previous drafts, I've tried to report a list of failed constraints. I haven't gotten any negative feedback on that, but then again, I'm not sure if anyone's noticed it. :)

From: Jim Barnett [mailto:Jim.Barnett@genesyslab.com]
Sent: Friday, December 7, 2012 7:25 AM
To: public-media-capture@w3.org
Subject: making progress on error handling

As I understand Anant's proposal,  the APIs will raise exceptions only for problems that can be detected at call time - so things like arg type mismatch, etc.  Other errors will be signaled by raising error events.

My first concern is coming up with a list of the errors we want to define.  Once we do that, we can define types and attributes for them etc.  (We also have to make sure that the exceptions make it into the spec.)  So here's a  rather haphazard start at listing (some of) the errors we will need.

In the current gUM draft, the only error I see is NavigatorUserMediaError.  It has a 'code' attribute, and the only value defined for it is 1, meaning "permission denied".  Now, if we include mandatory constraints, another kind of error is possible, namely that no device satisfies the constraints.  However, to avoid fingerprinting, we may want to use the same "permission denied" code for a failed constraint.  That way the app won't know whether the user refused permission for the device, or simply didn't have it.

On the other hand, if we go the route of allowing apps to build dummy tracks and assign them properties, so that they can be used for negotiation, we have to deal with the errors that can arise when the track is connected to a source device that lacks the specified property.  This is really the same sort of error as the failure of a mandatory constraint.  Do we again want to use "permission denied" for this case?

Also, what happens if a device that is being used is disconnected or somehow fails?  Is that an error that we should detect and signal?  Is that a new 'device-unavailable' error?

On the recording side, we have one set of well-defined errors, which are currently called "recordingwarning"  (we may want to change the name).  This event catches state errors, for example when the app calls stopRecording when recording hasn't been started.   Since these events are really catching errors in programming logic, we can define all the places that they occur.  The main question is what kind of data they should have.  (Should they contain a field indicating the current state, or one indicating what the state would have to be for the command to be legal?)

The set of 'recordingerror's is much messier.  This indicates that something has gone wrong at the platform-level.  Given the wide variety of platforms webRTC can end up running on, it's not clear to me how precisely we can define this set.  Among possible errors are:

*         You've asked for an unsupported format

*         You've asked for an impossible combination of formats  (I'm assuming that container formats put restrictions on the audio and video formats that they embed)

*         You've asked for a buffer size that I don't support (too big or too small)

*         Out of memory

*         You've added a track while recording is going on, and the container format doesn't support that (this could be treated as a recordingwarning as well, but it doesn't look much like a state error)

*         Hardware or software effecting the transcoding (something's gone wrong and the UA can no longer produce the specified format)

*         ??? I'm sure that there are all sorts of other problems that I haven't thought of.

Please send me comments and let me know what else you can think of.  Once we've had enough discussion, I'll send around the full list of errors, and we can discuss types, attributes, etc.


-          Jim