W3C home > Mailing lists > Public > public-webrtc@w3.org > October 2013

Re: RTCError, DOMError, and... what happened?

From: <piranna@gmail.com>
Date: Thu, 10 Oct 2013 22:37:45 +0200
Message-ID: <CAKfGGh1FErrX4d4Megm34Kst0Cepae6-zg6cFqLK-5PuNqNqEQ@mail.gmail.com>
To: Adam Roach <adam@nostrum.com>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
+1, error debugging of WebRTC webapps is a pain in the *ss... :-(

2013/10/10 Adam Roach <adam@nostrum.com>:
> I recently went into the WebRTC spec to look up something regarding error
> handling, and was quite surprised to find some nontrivial changes to how
> this is all handled.
> The first thing that's changed is that the code names have all been
> converted to camel case. That's fine. I mean, it's purely cosmetic, and it
> breaks everything, but I guess it's a developing spec, so we can deal with
> that.
> What I'm finding a most perplexing, though, is that these were converted to
> raw DOMErrors, rather than defining RTCError as a subclass of DOMError. In
> particular, I'm more than a little agitated that we've thrown away our
> "message" field that we were using before. This provided invaluable
> diagnostic information for developers. Is there some reason *why* we can't
> derive RTCError from DOMError in the same way as we're apparently doing for
> RTCSdpError? (While we're at it, I'll point out that simply saying
> "something is wrong on line x, you go figure it out" is a bit unsatisfying
> as well -- we should have a "message" field here as well.)
> The other thing that makes me a bit sad here is that I can't find any
> discussion of this error handling change anywhere in the mailing list
> archives. Did I simply miss this the conversation, or did it result from
> some non-public exchanges?
> /a

"Si quieres viajar alrededor del mundo y ser invitado a hablar en un
monton de sitios diferentes, simplemente escribe un sistema operativo
 Linus Tordvals, creador del sistema operativo Linux
Received on Thursday, 10 October 2013 20:38:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:51 UTC