Re: New error events

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.


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