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

Error Handling

From: Anant Narayanan <anant@mozilla.com>
Date: Fri, 12 Oct 2012 12:47:37 -0700
Message-ID: <507873D9.2040300@mozilla.com>
To: public-webrtc@w3.org
All,

The specification is currently not very clear on handling error 
conditions. There are two primary ways in which we can signal errors to 
content: exceptions and failure callbacks.

In general, a rule of thumb we've been following while implementing the 
spec in Firefox is to raise exceptions for anything that can be detected 
as an error in a synchronous manner (i.e. in <50ms). For error 
conditions that take longer to detect, we invoke the failure callback 
with an appropriate string.

Concretely, this would mean, as an example:

pc.createOffer("haha", "this is not a callback");

will generate an exception, since it is very easy to detect that the 
first parameter is not a RTCSessionDescription and the second parameter 
is not a function.

However, a call like:

pc.setLocalDescription({
   type: "offer",
   sdp: "...valid SDP..."
}, onSuccess, onError);

will invoke the failure callback if the SDP is syntactically correct but 
semantically wrong.

There are some ambiguous areas, like:

pc.createOffer({
   type: "offer",
   sdp: "a: not valid sdp\n"
}, onSuccess, onError);

In theory, it is possible to detect that the SDP is syntactically 
invalid in a synchronous manner, but it also means we need to have a SDP 
parser available as close to the DOM implementation as possible. In 
Firefox, that is not the case, therefore we invoke the failure callback 
in this particular case.

In general, where there is ambiguity we favour invoking the failure 
callback over throwing an exception. Exceptions are only used for the 
"obviously" wrong input parameters.

Because failure callbacks are likely to be more often used than 
exceptions, omitting a failure callback could lead to painful debugging 
scenarios where an error has occurred but the content does not know why. 
In light of this, I would also like to propose making failure callbacks 
mandatory (they aren't currently, but in the Firefox implementation they 
are). This part of the proposal is distinct from the previous 
suggestions, but is still something I'd like to see happen, because it 
promotes code hygiene. While writing example code for WebRTC, I have 
found it immensely useful when Firefox throws an exception because I 
haven't provided a failure callback.

I'd like to take this general idea and write down the exact behavior for 
each error condition, but before undertaking that, it would be great to 
hear feedback on whether this seems like a reasonable direction to go in.

Regards,
-Anant
Received on Friday, 12 October 2012 19:47:57 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:30 UTC