Re: New error events

On 3/4/13 9:32 PM, Eric Rescorla wrote:
> Given that we have opted not to do that for error callbacks, this
> seems to make things less consistent and more confusing.

I remember this a bit differently. I think we said that we should stick 
to error callbacks for errors that happen as result of something the app 
did (but use events for errors that occur unrelated to application actions).

But I also think we said that we should use DOMError's as far as 
possible, and when there are no suitable DOMError names defined we 
should ask for its definition (as said in 
https://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#error-names-0).

Harald has an Action to come up with a concrete proposal I believe 
(http://www.w3.org/2011/04/webrtc/mediacap/track/actions/14).

--Stefan
>
> -Ekr
>
>
> On Mon, Mar 4, 2013 at 12:28 PM, Travis Leithead
> <travis.leithead@microsoft.com <mailto: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 <mailto:ekr@rtfm.com>]
>     *Sent:* Sunday, March 3, 2013 4:48 PM
>     *To:* Justin Uberti
>     *Cc:* Jim Barnett; public-webrtc@w3.org <mailto: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
>                  >
>                  >
>                  >
>
>                 ____
>
>             __ __
>
>         __ __
>
>     __ __
>
>

Received on Thursday, 21 March 2013 14:34:21 UTC