RTCError, DOMError, and... what happened?

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 Thursday, 10 October 2013 20:31:54 UTC