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

Re: Operations in invalid states: Exceptions don't make sense.

From: Adam Bergkvist <adam.bergkvist@ericsson.com>
Date: Thu, 27 Jun 2013 11:00:01 +0200
Message-ID: <51CBFF11.1080102@ericsson.com>
To: Jim Barnett <Jim.Barnett@genesyslab.com>
CC: Gili <cowwoc@bbs.darktech.org>, "public-webrtc@w3.org" <public-webrtc@w3.org>
On 2013-06-26 14:48, Jim Barnett wrote:
> In the standard state machine model, firing the event handler is part
> of handling the event, so the next operation wouldn't be pulled off
> the queue until the event handler completed. So the state can't
> change while the event handler is operating. Thus the 'wrong state'
> problem you're worried about can't occur.  For this model to work,
> though, there have to be limitations on what can go in an event
> handler.  It can queue  other asynch operations, but it can't grab
> the thread and not release it.

We're on the same page here, when I said that it's not certain that the 
function will pass the state check, I was referring to the state check 
that's done when the operation is picked up from the operation queue and 
not when the function is called inside the event handler (we don't have 
the second type of check with our current approach).

> - Jim
> P.S.  Of course, it can still be the case that the state is correct
> when you queue the operation, but has changed by the time  you pull
> the event off the queue, which is why you have to check state when
> you execute the operation, not when you queue it.

This was what I was referring to in my example. We need to check the 
state in the async operation, and do an async error with 
InvalidStateError. So far, I haven't seen any other web API that does that.

Received on Thursday, 27 June 2013 09:00:27 UTC

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