RE: New error events

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