Re: New error events

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>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> 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
> >
> >
> >
>
>
>