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

Having read the discussion about uncertainty on DOMError etc. I think we should have something that is not unstable and that we can write applications that use. 

I propose we move that back to an RTCError object that includes a message field. 



On Oct 10, 2013, at 2:31 PM, Adam Roach <adam@nostrum.com> wrote:

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

Received on Saturday, 12 October 2013 16:55:55 UTC