- From: Adam Bergkvist <adam.bergkvist@ericsson.com>
- Date: Tue, 6 Sep 2011 11:29:37 +0200
- To: Tommy Widenflycht (ᛏᚮᛘᛘᚤ) <tommyw@google.com>, Justin Uberti <juberti@google.com>
- CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
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
Received on Tuesday, 6 September 2011 09:30:15 UTC