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

On Thu, May 23, 2013 at 2:38 AM, Adam Bergkvist <adam.bergkvist@ericsson.com
> wrote:

> 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<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?


I';m not sure I understand what "this behavior" is. How would it be
observably
different from what Adam proposed.



>  [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


That SGTM.

-Ekr