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

I considered that, but that seems overly complex - should we add callbacks
to every single API? And what do we do if someone passes a string as the
callback parameter?

The idea of type checking is that it is a trivial check that can be
performed by the API layer, as opposed to a detailed check (e.g. sdp parse)
that has to happen at a lower layer. I agree that it's not completely black
and white though.
On Feb 22, 2013 12:15 AM, "Arnaud Morin" <arnaud1.morin@orange.com> wrote:

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