Using exceptions for error reporting (Re: RTCError, DOMError, and... what happened?)

On 10/23/2013 08:33 PM, cowwoc wrote:
>
>     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).
>

Sorry, when did we agree on this?

The spec (section 4.5.1 RTCPeerCOnnectionErrorCallback) currently says:

callback RTCPeerConnectionErrorCallback = void (DOMError error);

I've noted that we need to use RTCSdpError for setLocal/setRemote:

interface RTCSdpError : DOMError {
     readonly    attribute long sdpLineNumber;
};

I don't see a well-defined concept of "stack trace" that would make 
sense in your statement

 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.

This is easily solved without any API or implementation change.
The well-known Javascript way to handle this is to pass the information 
in the callback:

SetLocalDescription(desc, success, function(error) {
    whereiwascalledfrom = "call site 1";
    commonErrorHandling(error, whereiwascalledfrom)
})

The diagnostics are, as Adam said, an implementation matter.