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

     I am getting increasingly annoyed with the state of WebRTC error 
reporting. Granted, the problems mentioned below are specific to Chrome 
but I get the feeling that Chrome hasn't devoted more attention to this 
because the spec is in flux.

     Take a look at some of the error messages I ran into: 
https://code.google.com/p/webrtc/issues/detail?id=2556

     I think we already agreed on the following:

 1. Callback must be passed an exception (not a string, as is currently
    the case in Chrome).
 2. The exception must contain a message field for human consumption.
    Developers should never have to parse the message for useful
    information, we should add separate properties for that.

     I suggest going beyond this and adding the following requirements:

 1. The exception stack-trace SHOULD include the caller of the WebRTC
    function. Currently it is truncated due to implementation details,
    starting inside the WebRTC function. Right now if I invoke
    setLocalDescription() from 10 locations in my code, WebRTC tells me
    that setLocalDescription() ran into a problem but I have no idea
    which of the 10 locations were at fault.
 2. The message MUST indicate which input parameter was at fault (the
    parameter name)
 3. The message SHOULD indicate which subset of the input parameter was
    at fault (line number or name of sub-property).

     What do you think?

Gili

On 10/10/2013 5:43 PM, cowwoc wrote:
>
>     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
>>>
>>
>