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

     Regardless of what exception type gets used, I don't believe the 
move is blocking us from improving error reporting in a manner that 
won't break backwards-compatibility in the future.

Gili

On 10/10/2013 5:35 PM, Travis Leithead wrote:
> Just to throw out a note of caution, I believe that Anne now intends to deprecate/remove DOMError altogether, and just use DOMException objects directly. The goal as I infer it, is to unify all exception/error processing in the DOM into the one object for simplicity and uniformity. (The multitude of *Error objects is ECMAScript is not seen as a great design.)
>
> -----Original Message-----
> From: cowwoc [mailto:cowwoc@bbs.darktech.org]
> Sent: Thursday, October 10, 2013 2:10 PM
> To: public-webrtc@w3.org
> Subject: 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:44:04 UTC