Re: making progress on error handling

On 2012-12-07 16:25, Jim Barnett wrote:
> 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.

A conclusion from previous discussions on this was that having the same 
error code for "user did not grant access", "no device" and "failed to 
meet mandatory constraints" doesn't protect the user much since the app 
can be rather successful in distinguishing the first from the two ladder 
by timing (the two ladder will probably return right away unless we 
deliberately delay them).

There's also an ongoing in the "How to check if permission denied?" thread.
http://lists.w3.org/Archives/Public/public-media-capture/2012Nov/0045.html

/Adam

>
> 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
>

Received on Wednesday, 12 December 2012 06:39:04 UTC