Re: Error handling

On Tue, Sep 6, 2011 at 3:56 PM, Ian Hickson <ian@hixie.ch> wrote:

> On Mon, 5 Sep 2011, Tommy Widenflycht (á~[~Oá~Z®á~[~Xá~[~Xá~Z¤) wrote:
> >
> > TYPE_ERROR is common as well and is probably the correct action for the
> > three first cases.
>
> Some of these are already handled:
>
> > On Sat, Sep 3, 2011 at 00:15, Justin Uberti <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
>
> That's handled by WebIDL.
>

OK.

>
>
> > > - processSignalingMessage receives an malformed signaling blob
> > > - processSignalingMessage receives an incompatible description (no
> codecs,
> > > incompatible codecs, incompatible crypto)
>
> That's handled by the ICE and SDP specs, in theory. The API doesn't throw
> an exception because the processing has to be async.
>

I don't think the processing has to be async here, but it certainly could
be. In any case, the application needs to be informed somehow, to either
reply with some sort of error to the other side, and/or to alert the local
user that the session has failed.


>
> > > - an internal failure occurs while processing an arbitrary API call
>
> Internal failures are bugs, we can't very well specify what should happen
> in the case of bugs. :-)
>

Is failing silently really the best thing to do, as opposed to throwing some
generic exception?


>
> > > - connectivity fails to establish, or is lost mid-call
>
> That would cause the ICE Agent to attempt to reestablish the connection.
>

Yes, but it needs to give up at some point.


>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'