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

Hi,
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?

Cheers,
Arnaud.

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