W3C home > Mailing lists > Public > public-webrtc@w3.org > October 2013

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

From: Harald Alvestrand <harald@alvestrand.no>
Date: Thu, 24 Oct 2013 08:31:48 +0200
Message-ID: <5268BED4.6020901@alvestrand.no>
To: public-webrtc@w3.org
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.
Received on Thursday, 24 October 2013 06:32:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:51 UTC