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

As do I.

On 22 May 2013 13:55, Eric Rescorla <ekr@rtfm.com> wrote:
> I agree with Adam here.
>
>
> On Wed, May 22, 2013 at 12:31 AM, Adam Roach <adam@nostrum.com> wrote:
>>
>> Currently, the WebRTC spec has some implication that a PeerConnection's
>> signalingState should be checked at the time an operation (e.g.,
>> setRemoteDescription) is enqueued, and an that an exception should be thrown
>> if the state is not appropriate for the indicated operation at that time,
>> regardless of how the already-enqueued operations may change that state.
>>
>> This is covered in section 4.6.1 (Error Handling / General Principles): "
>> An exception MUST be thrown... [if a] function call was made when the
>> RTCPeerConnection is in an invalid state, or a state in which that
>> particular function is not allowed to be executed."
>>
>> This interacts badly with the conceptual model that we currently have
>> around operations, which is that scripts are allowed to make several calls
>> on the PeerConnection without first waiting for the prior one to complete
>> (with the result being that the PeerConnection queues such operations until
>> the previous one completes).
>>
>> Roughly speaking, this means that the PC state can be okay at the time an
>> operation is enqueued, but invalid by the time the operation is executed.
>> Conversely, the PC state may be invalid at the time an operation is
>> attempted, but be changed to an invalid state by the time the operation is
>> to be run.
>>
>> The first set of circumstances requires us to allow async error callbacks
>> for invalid states.
>>
>> The second set of circumstances means that synchronous checks will, under
>> some circumstances, throw exceptions when it is inappropriate to do so.
>>
>> In other words, I think this points to an absolute requirement to check
>> states async and an absolute prohibition on checking them synchronously.
>>
>> The specific change I'm requesting is:
>>
>> Remove the second bullet from section 4.6.1
>> Change step 1 of "addStream" in section 4.3.2.2 to end with "...abort
>> these steps, and call the addStream error callback with an RTCError of
>> INVALID_STATE"
>> Remove step 1 from "close" in section 4.3.2.2
>> Change step 2 of "addStream" in section 4.3.2.2 to end with "...abort
>> these steps, and call the removeStream error callback with an RTCError of
>> INVALID_STATE"
>> Change the first bullet of "setLocalDescription" in section 4.3.2.2 to end
>> with "...abort these steps, and call the setLocalDescription error callback
>> with an RTCError of  INVALID_STATE"
>> Change step 1 of section 5.1.2 to end with "...call the createDataChannel
>> error callback with an RTCError of INVALID_STATE."
>> Remove step 2 from section 5.2.3 (for this reason and for the reason that
>> readyState no longer exists)
>> Change step 1 of section 7.2.1 to end with "...call the getStats error
>> callback with an RTCError of INVALID_STATE."
>> Change step 1 of section 8.2.2, setIdentityProvider to end with "...abort
>> these steps, and call the setIdentityProvider error callback with an
>> RTCError of  INVALID_STATE"
>>
>>
>> /a
>
>

Received on Wednesday, 22 May 2013 21:51:58 UTC