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

On 2013-06-24 13:44, Jim Barnett wrote:
> Yes, but are you going to signal an error if the developer makes a
> call when you're in a processing state?  In that case, you'll end up
> with a lot of polling code, sitting  around waiting for the state to
> change.  That's an ugly programming model.  Now if it's the case that
> some operations can succeed when you're in the processing state, then
> that's a good argument for having a processing state, since  it now
> behaves like a first-class state, with a differentiated response to
> different events.  But if all operations are going to fail until the
> processing is done, the queuing model is cleaner.
>

Yes, an API call in the wrong state should result in a state error. 
Regarding polling the state, we already got state verification with the 
queuing model; the difference is that it's done async (for some 
operations). It's usually not a problem since this kind of state is 
mostly based on application context. For example, the PeerConnection 
will be in a processing state after a call to setLocalDescription() and 
until the success or error callback fires.

Code that uses the success and error callbacks will look the same. It's 
only questionable code like (Jan-Ivar's example):

     // Bad code. state=have_local_offer
     pc.setRemoteDescription(answer1, success, mayfail);
     pc.setRemoteDescription(answer2, success, mayfail);

that will behave differently. The second call will *always* throw an 
exception because the PeerConnection is in a processing state as a 
result of the first call. With a queue, the behavior is derived from 
rules that depends on what happens to the first call.

The processing states are real states. You can do anything beside call 
some the sensitive operations we currently queue.

/Adam

Received on Monday, 24 June 2013 12:47:50 UTC