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 10:17:40 UTC