RE: Error handling

On 2011-09-05 10:26, Tommy Widenflycht (ᛏᚮᛘᛘᚤ) wrote:
> TYPE_ERROR is common as well and is probably the correct action for 
> the three first cases.
>
> /Tommy
>
> On Sat, Sep 3, 2011 at 00:15, Justin Uberti <juberti@google.com 
> <mailto:juberti@google.com>> wrote:
>
>     The current specification indicates that INVALID_STATE_ERR
>     exceptions may be thrown if methods are called on a PeerConnection
>     that is in the wrong state. However, other sorts of errors can of
>     course occur:
>     - a bad object (i.e. not a MediaStream) is passed to addStream
>     - processSignalingMessage receives an malformed signaling blob
>     - processSignalingMessage receives an incompatible description (no
>     codecs, incompatible codecs, incompatible crypto)
>     - an internal failure occurs while processing an arbitrary API call
>     - connectivity fails to establish, or is lost mid-call
>
>     I think we may need to document/define some additional exception
>     types, as well as some sort of async onerror callback to indicate a
>     fatal session failure. I see that DOMException defines a SYNTAX_ERR
>     which could be used for the malformed blob case, but is there
>     something else that can be used for general internal errors?
>

A TYPE_ERROR exception will be thrown when an object passed to
addStream() is not a MediaStream, as specified by WebIDL. When a
signaling message, that doesn't begin with "SDP\n", is passed to
processSignalingMessage() it will be ignored. Generally, it's safer
to ignore errors that tend to happen post-development since applications
are typically not written to handle exceptions. Also, parsing of the
signaling messages may be asynchronous (which is currently the case in
Chrome, I believe) in which case the error reporting can't be
synchronous. I don't see a need for any additional exceptions to be
thrown at this point although I expect some asynchronous error handling
will have to be added once we have enough implementation experience.

/Adam