Re: New error events

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

Received on Sunday, 3 March 2013 15:21:57 UTC