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

On 24/10/2013 2:31 AM, Harald Alvestrand wrote:
>
>>     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;
> };

     My mistake. I misread this as an exception (DOMError vs DOMException).

> 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.
>

     I'm aware that you can do that, but why push the burden on the 
user? All major APIs I'm aware of communicate errors by way of 
exceptions (not strings) precisely because you want a stack-trace. 
Javascript Promises work the same way.

Gili