Re: New error events

Since I think this would be implemented as an extension of the RTCError
that is defined in the PeerConnection spec, and via an onerror callback on
PeerConnection, I think most of the details here would be
PeerConnection-specific.

Recording could of course use a similar style for its own error handler.



On Sun, Mar 3, 2013 at 7:21 AM, Jim Barnett <Jim.Barnett@genesyslab.com>wrote:

> Some of the enum values will be specific to the individual APIs. For
> recording will need "out of memory", which won't be needed/common in the
> other APIs.  Is there a way that gUM could define its core set, and then
> webRTC could add transport-related items, etc.?  Recording would inherit
> and extend the gUM set, but not need the webRTC items.  This seems like an
> obvious place for a bit of inheritance.
> Jim
>
> On Mar 2, 2013, at 5:18 PM, "Justin Uberti" <juberti@google.com<mailto:
> juberti@google.com>> wrote:
>
> Yeah, I was thinking the same thing the other day, in the context of
> "internal error". This stuff happens and robust apps are going to want to
> at least phone home about this.
>
> Do you have a suggestion for the enums (generic error, transport failure,
> security failure)?
>
>
> On Sat, Mar 2, 2013 at 1:51 PM, Jim Barnett <Jim.Barnett@genesyslab.com
> <mailto:Jim.Barnett@genesyslab.com>> wrote:
> We need a similar set of error events for recording. It would be good to
> find a way to do this without creating a lot of new classes. Could we
> define a single that gUM, webRTC, recording and takePhoto could use?
> Jim
>
> On Mar 2, 2013, at 9:17 AM, "Eric Rescorla" <ekr@rtfm.com<mailto:
> ekr@rtfm.com>> wrote:
>
> > Hi folks,
> >
> > I'm starting to come to the conclusion that we need some ways
> > to implement error notification as distinct from either
> setLocal/setRemote
> > or state notification. Here are some examples of events that don't
> > seem to me to have a logical way to report to the programmer:
> >
> > - ICE allocation failed (e.g., couldn't actually allocate sockets for
> > each component.) Obviously, you could report that allocation
> > is *done* but it's not like a naive application is going to notice
> > that candidates are missing.
> >
> > - DTLS-SRTP handshake failed.
> >
> > - The ever-famous "internal error".
> >
> > I would suggest that we have some sort of "onerror" event, perhaps
> > with a numeric error enum and a string that is explanatory.
> >
> > Thoughts,
> > -Ekr
> >
> >
> >
>
>
>
>
>