Re: New error events

Given that we have opted not to do that for error callbacks, this
seems to make things less consistent and more confusing.

-Ekr


On Mon, Mar 4, 2013 at 12:28 PM, Travis Leithead <
travis.leithead@microsoft.com> wrote:

>  Let me just take this opportunity to ask that you define the error model
> concept in terms of the "DOMError" error object reporting mechanism which
> we discussed in a previous thread [1] and not use numeric error numbers. *
> ***
>
> ** **
>
> [1] http://lists.w3.org/Archives/Public/public-webrtc/2012Dec/0115.html***
> *
>
> ** **
>
> ** **
>
> *From:* Eric Rescorla [mailto:ekr@rtfm.com]
> *Sent:* Sunday, March 3, 2013 4:48 PM
> *To:* Justin Uberti
> *Cc:* Jim Barnett; public-webrtc@w3.org
> *Subject:* Re: New error events****
>
> ** **
>
> ** **
>
> On Sun, Mar 3, 2013 at 4:16 PM, Justin Uberti <juberti@google.com> wrote:*
> ***
>
>  We'll also need some way to indicate whether a given error is a fatal
> error, or just a warning, so the app knows what to do.****
>
> ** **
>
> For example, a DTLS handshake error is likely fatal, whereas failure to
> create UDP sockets might not be.****
>
>  ** **
>
> Yeah. Though in the case we are looking at, it generally is, because it
> means we****
>
> don't have network ports for one of our components.****
>
> ** **
>
> -Ekr****
>
>   ****
>
>   ** **
>
> On Sat, Mar 2, 2013 at 3:18 PM, Justin Uberti <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>
> 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
> >
> >
> >
>
> ****
>
>  ** **
>
>  ** **
>
>  ** **
>