Re: Error Handling

This seems to make sense to me - and it seems to be a codification of 
what we're already doing.

I suggest we "just do it" and include a section saying what Anant's 
saying below as "principles of error handling" in the spec.

The next steps of work seem to be:
- Look at each call and see what exceptions they generate for various errors
- Look at each callback and see what information they should pass back

One area where more text may be needed: I'm not very clear at the moment 
on what information we return in a callback - for instance, with SDP 
parse errors, it would be nice to know where in the SDP the parse error 
was detected - but I don't know if we can indicate that at the moment.

On 10/12/2012 09:47 PM, Anant Narayanan wrote:
> 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 Monday, 22 October 2012 06:11:20 UTC