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

On 2013-02-22 18:28, Martin Thomson wrote:
> On 22 February 2013 08:46, Justin Uberti <> 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.


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