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

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

Received on Friday, 22 February 2013 03:32:56 UTC