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

+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
Unix."
– Linus Tordvals, creador del sistema operativo Linux

Received on Thursday, 10 October 2013 20:38:32 UTC