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

On 05/27/2013 11:00 AM, Adam Bergkvist wrote:
> On 2013-05-23 14:23, Jim Barnett wrote:
>> If you split the queueable operations into two, wouldn't the second,
>> queued, operation also have to check the state before it executed?
>> (And raise an asynch error if the state is wrong.)  Another operation
>> could  have changed the state between the time  the operation is
>> queued and the time it executes.  If that's the case, there's nothing
>> wrong with checking state before we queue the operation, but it isn't
>> really necessary.
>
> Yes, depending on how we describe this we might have to check the 
> state again, abort and possibly report an error. We have some 
> algorithms that describe how the UA reacts to external events and runs 
> some operations (incoming stream, new ice candidate, ...), and in 
> those cases it simply aborts if the PeerConnection is closed. Picking 
> up a previously queued task from the operations queue is quite similar 
> I think. I believe the reason to not report an error in those cases is 
> that the script should already have been notified that the 
> PeerConnection has been closed down and we don't want every single 
> error handler we have to start firing after that point; the 
> PeerConnection is closed and done.
>
> So my vote is to check for the closed state before queuing the task 
> and then stop processing tasks when the PeerConnection is closed. That 
> would be similar to aborting queued tasks if the PeerConnection is 
> closed. Note that this doesn't rule out checking for other states, 
> beside closed, when a task is picked up and run.

I just want to make sure we guarantee the success/failure property:

When you call an <action>, one out of 3 things happen:

- You get an exception thrown
- The call returns normally, and later an error callback is called
- The call returns normally, and later a success callback is called

The language you're proposing sounds as if we'll violate that property 
if the connection is closed after the call returns normally, but before 
the task is dequeued.

I don't think we should violate that property.

>
> /Adam
>

Received on Monday, 27 May 2013 12:31:43 UTC