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

On 2013-05-23 11:23, Eric Rescorla wrote:
> On Thu, May 23, 2013 at 2:13 AM, Adam Bergkvist
> <adam.bergkvist@ericsson.com <mailto:adam.bergkvist@ericsson.com>> wrote:
>
>     Thanks for bringing this up; there's some text that hasn't been
>     properly updated WRT the operation queuing.
>
>     Not all functions you mention above are candidates to be queued. The
>     spec lists createOffer, setLocalDescription, createAnswer and
>     setRemoteDescription [1]. It may be that this list should be updated.
>
>     For the calls that may be queued, we have the option to split them
>     up into a section that first runs on the main loop and checks if the
>     PeerConnection isn't closed, and then adds a task to the queue (that
>     also may need to check the state when executed). The first check
>     would be valid since the PeerConnection can't recover from the
>     closed state. This would be more consistent with non-queueable
>     operations and would avoid queuing operations on a closed
>     PeerConnection.
>
>
> 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?

> [0] Note that we definitely see people calling .close() twice and having
> it throw an exception is a recipe for problems.

I vote for making close() just return if the PeerConnection is already 
closed. That's the behavior of WebSocket and EventSource.

/Adam