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

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.  

- Jim

-----Original Message-----
From: Adam Bergkvist [mailto:adam.bergkvist@ericsson.com] 
Sent: Thursday, May 23, 2013 6:17 AM
To: Eric Rescorla
Cc: Adam Roach; public-webrtc@w3.org
Subject: Re: Operations in invalid states: Exceptions don't make sense.

On 2013-05-23 11:55, Eric Rescorla wrote:
> On Thu, May 23, 2013 at 2:38 AM, Adam Bergkvist 
> <adam.bergkvist@ericsson.com <mailto:adam.bergkvist@ericsson.com>> wrote:
>
>     On 2013-05-23 11:23, Eric Rescorla wrote:
>         I don't see the advantage of this, it just seems like it's
>         another place
>         to go
>         wrong. [0]
>
>         You can still detect closed in the main loop and then queue a
>         task to
>         fire the error cb. This isn't hard and gives you a consistent
>         interface.
>
>
>     So you're OK with the idea in general, but would like to have an
>     async error instead of the exception?
>
>
> I';m not sure I understand what "this behavior" is. How would it be 
> observably different from what Adam proposed.

Adam R made the assumption that methods like addStream() and
removeStream() are queued, but that's not the case according to the spec. So, e.g., addStream() (not queueable) would directly check for the closed state on the main loop when called. setLocalDescription (queable) would (in Adam R's proposal) check the when it's picked up from the queue to be executed. The difference would be an exception in the first case and an async error after the call in the second. So my proposal was to split a queueable method into two parts where the first part runs on the main loop and checks for the closed state (similar to non-queueable
methods) and the second part, that does the work, is queued.

/Adam

Received on Thursday, 23 May 2013 12:24:24 UTC