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

     Perhaps it would be more beneficial to subclass DOMError (in spite 
of what Anne said) and drop the subclass once the message field is 
added. Ideally we should say that the API throws a "DOMError subclass 
containing a message field" without mentioning the specific subclass 
name. This way we can remove RTCError in the future and drop the wording 
"subclass containing a message field" in the future without breaking 
backwards compatibility.

Gili

On 10/10/2013 4:47 PM, Jim Barnett wrote:
> As I recall, there was public discussion of this, but it may have occurred primarily on the media-capture list.  The DOM group (Anne van Kesteren?) urged us not to subclass DOMError, and said that they planned add the message field to DOMError since it was generally useful.  They also said that we could get new DOMErrors added if we need them.
>
> Does anyone else have more or different information to add?
>
> - Jim
>
> -----Original Message-----
> From: Adam Roach [mailto:adam@nostrum.com]
> Sent: Thursday, October 10, 2013 4:31 PM
> To: public-webrtc@w3.org
> Subject: 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 21:10:57 UTC