RE: New error events

But recording doesn’t know anything about PeerConnection, and neither does gUM.  If there is going to be a basic error class that we all extend, doesn’t it belong in the gUM spec?


-          Jim

From: Justin Uberti [mailto:juberti@google.com]
Sent: Sunday, March 03, 2013 7:12 PM
To: Jim Barnett
Cc: Eric Rescorla; public-webrtc@w3.org
Subject: Re: New error events

Since I think this would be implemented as an extension of the RTCError that is defined in the PeerConnection spec, and via an onerror callback on PeerConnection, I think most of the details here would be PeerConnection-specific.

Recording could of course use a similar style for its own error handler.


On Sun, Mar 3, 2013 at 7:21 AM, Jim Barnett <Jim.Barnett@genesyslab.com<mailto:Jim.Barnett@genesyslab.com>> wrote:
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><mailto: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><mailto: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><mailto: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
>
>
>