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

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