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

Re: Proposal for error handling (programming vs runtime errors)

From: Adam Bergkvist <adam.bergkvist@ericsson.com>
Date: Mon, 25 Feb 2013 10:18:46 +0100
Message-ID: <512B2C76.5030605@ericsson.com>
To: Martin Thomson <martin.thomson@gmail.com>
CC: Justin Uberti <juberti@google.com>, Arnaud Morin <arnaud1.morin@orange.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>, Cullen Jennings <fluffy@cisco.com>
On 2013-02-22 18:28, Martin Thomson wrote:
> On 22 February 2013 08:46, Justin Uberti <juberti@google.com> wrote:
>> I considered that, but that seems overly complex - should we add callbacks
>> to every single API? And what do we do if someone passes a string as the
>> callback parameter?
>
> Yes.  There's a line to draw, and to a large extent, the choice of
> where is arbitrary.
>
> Clearly, there are many different ways to implement this as well.  We
> want to draw the line in a place that offers implementations a degree
> of flexibility.  This is as good a trade-off as any.
>
> Also, as we've already agreed, we should make it doubly clear that any
> and all callbacks occur *after* the browser has returned to a stable
> state.  Even if an implementation discovers some callback-generating
> errors synchronously, it needs to wait before firing the callback.
> Unexpected recursion makes it much harder to write code to an API.
>

I think Justins reasoning makes sense, but as Cullen says, it's perhaps 
not entirely black and white what are programming errors vs run-time. 
You can blame the programmer for most stuff in the end. I think we 
should align with other Web APIs and use "invalid state", "syntax 
error", "type error" with friends to say that an API call doesn't meet 
the prerequisites to even run, and async error reporting when the 
prerequisites are met, but the call fails for other reasons.

In most cases it's rather clear to which category an error belongs, but 
the SDP validation is a gray zone. It's a bit similar to URL resolution, 
which is done synchronously in the WebSocket and EventSource APIs, but 
our decision to do that async makes sense for implementation reasons.

/Adam
Received on Monday, 25 February 2013 09:19:13 UTC

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