W3C home > Mailing lists > Public > public-webrtc@w3.org > February 2013

Re: Proposal for error handling (programming vs runtime errors)

From: Arnaud Morin <arnaud1.morin@orange.com>
Date: Fri, 22 Feb 2013 09:15:11 +0100
Message-ID: <5127290F.1020800@orange.com>
To: Justin Uberti <juberti@google.com>
CC: "Cullen Jennings (fluffy)" <fluffy@cisco.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Why not using callback errors all the time? This way, the developer only 
need to take care of callback methods to handle error.
FMHO, the line between "The type of a parameter does not match the 
defined type" and "Malformed parameters" is very fuzzy, it's almost the 
same, no?


On 22/02/2013 08:00, Justin Uberti wrote:
> As I spell out in the document, the cases where you use an exception 
> are all cases where an IPC is not needed. Exceptions are really just 
> for sanity-checking the input, similar to how ASSERTs are typically 
> used in C++ programs; they tell you you did something wrong, but you 
> shouldn't try to solve this by wrapping the method call in a try/catch 
> block, since the exception indicates that you're not using it properly.
> Perhaps the terms 'programming' and 'runtime' aren't the best way of 
> expressing this, but I think the general rules of the road should be 
> pretty clear. Naturally, the part that really matters is the specifics 
> for each error; I did define the errors that I think we need and what 
> causes them to be generated. Let me know if I got any of these wrong, 
> or missed something important.
> On Thu, Feb 21, 2013 at 7:32 PM, Cullen Jennings (fluffy) 
> <fluffy@cisco.com <mailto:fluffy@cisco.com>> wrote:
>     I'm not disagreeing with you on the end outcome of what of things
>     you want to put in exceptions versus error callbacks but I don't
>     think this distinction of runtime vs programming makes any sense.
>     Many programming errors could cause INVALID_SESSION_DESCRIPTION
>     and many runtime roots could cause INVALID_PARAMETER_ERR. I don't
>     think this make sense as a way of dealing the problem. The real
>     issue seems to me to be what the code will look like that uses
>     these and where in the browser the error can be detected.
>     Particularly for async calls where the error is detected on
>     another thread, using an exception is very hard. It does not
>     matter if this was an runtime or programming error, it still hard
>     to use an exception.
>     As a way forward, lets define the error we need, what causes them,
>     and ignore the runtime vs programming distinction.
>     On Feb 21, 2013, at 1:06 PM, Justin Uberti <juberti@google.com
>     <mailto:juberti@google.com>> wrote:
>     > Following up on a previously assigned action. Some of this is
>     already in the spec, but there were enough gray areas that I think
>     we need to add more detail. Please comment, either via mail or in
>     the document at
>     https://docs.google.com/document/d/1_npj3RJmPcPwo4jLD44VcTW-juRBAKJdjJceGOw6sRg/edit#.
>     >
>     > ----
>     > WebRTC Error Handling
>     >
>     >
>     > WebRTC provides two mechanisms for errors to be returned to the
>     application - exceptions, which are returned synchronously, and
>     completion callbacks, which are returned asynchronously.
>     >
>     > The operations that are async in the WebRTC API use this
>     technique because they may take nontrivial time to complete,
>     and/or require inter-thread or inter-process and communication.
>     The callback informs the application that the operation is
>     complete (and can now do something else), and what the result of
>     the operation was.
>     >
>     > To understand when an error should be returned via an exception,
>     or via an async callback, the guideline is simple: programming
>     errors (e.g. API called at wrong time or with parameters of the
>     wrong type) should always result in an exception. Runtime errors,
>     such as an error in the syntax of a parameter, or failure to apply
>     a desired operation, should always result in a callback.
>     >
>     > Programming errors are explicitly defined as the following
>     conditions:
>     >       • The state of the object does not match the preconditions
>     for the API call (e.g. setLocalDescription on a closed PeerConnection)
>     >       • The type of a parameter does not match the defined type
>     (e.g. setLocalDescription("foo"), setLocalDescription(null),
>     setLocalDescription({foo:42}).
>     >
>     > All other errors are considered runtime errors, including:
>     >       • Malformed parameters, or parameters that are incorrect
>     for the given object state (e.g.
>     setLocalDescription({type:"answer", sdp:<sdp>} on a PeerConnection
>     in the "stable" state; setLocalDescription({type:"answer",
>     sdp:"barf"})
>     >       • Failure to parse SDP
>     >       • Failure when applying SDP
>     >
>     > Programming errors result in an exception being thrown with either:
>     >       • INVALID_STATE_ERR as the name (a generic DOM exception), or
>     >       • INVALID_PARAMETER_ERR (TBD where this is defined).
>     >
>     > Programming errors prevent any state change and are always
>     recoverable.
>     >
>     > Runtime errors result in a error callback with an RTCError
>     object. The RTCError object may use the following names:
>     >       • INVALID_STATE(?) (Incorrect type of SDP for current
>     state, recoverable)
>     >       • INVALID_SESSION_DESCRIPTION (SDP failed to parse, or not
>     suitable, recoverable)
>     >       • INCOMPATIBLE_CONSTRAINTS (Unsatisfiable constraints to
>     async function, recoverable)
>     >       • INCOMPATIBLE_MEDIASTREAMTRACK (MediaStreamTrack is not
>     part of PeerConnection, recoverable)
>     >       • INTERNAL_ERROR (Failure occurred when setting local or
>     remote description, media subsystem is in bad state, not recoverable)
>     >
>     > Runtime errors may occur after state has already changed, and
>     may not be recoverable.
>     >
>     > References:
>     > WebRTC spec, section 4.6, Error Handling
Received on Sunday, 24 February 2013 22:48:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:41 UTC