RE: Error handling for TCPServerSocket

Thanks for your reply Jonas.

See inline below.

Claes

> -----Original Message-----
> From: Jonas Sicking [mailto:jonas@sicking.cc]
> Sent: den 16 maj 2013 00:51
> To: Nilsson, Claes1
> Cc: public-sysapps@w3.org; Edenbrandt, Anders; Isberg, Anders; Isaksson,
> Björn
> Subject: Re: Error handling for TCPServerSocket
> 
> On Wed, May 15, 2013 at 4:36 AM, Nilsson, Claes1
> <Claes1.Nilsson@sonymobile.com> wrote:
> > Hi Jonas,
> >
> > Se inline below.
> >
> > Claes
> >
> >> -----Original Message-----
> >> From: Jonas Sicking [mailto:jonas@sicking.cc]
> >> Sent: den 13 maj 2013 19:37
> >> To: Nilsson, Claes1
> >> Cc: public-sysapps@w3.org; Edenbrandt, Anders; Isberg, Anders;
> >> Isaksson, Björn
> >> Subject: Re: Error handling for TCPServerSocket
> >>
> >> On Mon, May 13, 2013 at 3:57 AM, Nilsson, Claes1
> >> <Claes1.Nilsson@sonymobile.com> wrote:
> >> > Hi Jonas,
> >> >
> >> > Yes, the error handling for TCPServerSocket might have to better
> >> defined.
> >> >
> >> > In the description of the steps for the TCPServerSocket
> constructor
> >> > I
> >> guess that we should add a statement saying that an exception is
> >> thrown if the server socket cannot be created, for example because
> >> the implementation does not support TCP server sockets.
> >>
> >> Well, if the implementation doesn't support TCP server sockets they
> >> shouldn't expose the TCPServerSocket constructor at all. This is
> >> probably worth pointing out in the spec. At that point it's clear
> >> that attempting to create one will yield an exception in Javascript.
> > [Claes] Yes and I assume that there are more error situations that
> will yield an exception, for example no contact with network layer.
> 
> We should definitely not throw an exception for "no contact with
> network". Exceptions should only be used when there's a clear bug in
> the code.
> 
> If we were to throw an exception for no connection with network, that
> would result in things working fine for the developer, but once he
> pushes his application to users, things will break horribly because an
> exception is thrown in the middle of the setup-code for the application
> which means that it ends up in a half-initialized state.
> 
> If there is no network connection, then either an error event should be
> fired indicating that setup failed, or the API should simply wait until
> network becomes available and at that point let the app know that setup
> is now complete.
> 
> These are exactly the type of error behaviors that needs to be defined
> and that is currently lacking in the spec.
> 
> One of the big reasons HTML is so messy is because it didn't define
> error behavior. This resulted in different implementations doing
> different things, all trying to "help along" as best they could, but
> all having different ideas of what that meant. The result was
> dramatically different behaviors that over time cross influenced each
> other but with no strategy, planning or thought-through solutions.
> 
> So I would argue that defining error behavior is at least as important
> as defining behavior in success cases. Success cases are easy to agree
> on, error behavior is what will see less testing and less planning,
> unless properly defined.

[Claes] I see that I was unclear here. The example I gave for throwing was expressed as "no contact with network layer". By that I meant that the situation when there is no contact with TCP due to issues with the TCP layer in the device, e.g. erroneous configuration. 

I completely agree on your view on throwing exceptions as result of bugs in the code, for example calling send() when the readyState is not "open", and your general statements on error handling. My ambition is to cover all potential error situations like that in the specification.

For dynamic asynchronous errors like "no contact with network" we have the error event. 

Furthermore, I assume that an application will use the Network Information API, http://www.w3.org/TR/2012/WD-netinfo-api-20121129/, to detect that there is network connection again so we do not need an event in the socket API for detecting this.

> 
> >> > However, I don't know if we need an event stating that the server
> >> > has
> >> been successfully set up. Would a successful execution of the server
> >> socket constructor be enough?
> >>
> >> I assume that setting up a server requires several long-running
> >> steps, i.e. steps that require IO. Such steps should not be taken
> >> synchronously from the TCPServerSocket constructor since that will
> >> result in jank in the UI of the application.
> > [Claes] I am not sure here. Which are the use cases for acting on a
> server setup confirmation event?
> 
> To let the application move on with other setup items. To display to UI
> to the user like "waiting for players to join".
> 
> > To keep the API as simple as possible wouldn't it be enough to use
> exception handling with the constructor for errors that are immediately
> discovered and the error event for asynchronous errors.
> 
> See above why exceptions are bad. Exceptions should be used in
> exceptional situations. Using exceptions to indicate normal modes of
> operation is a classical error to make when designing APIs in languages
> that support exceptions.
> 
> Having no network connection, or having another application already
> occupying an outgoing port, is not exceptional.
> 
> Another reason exceptions can't be used is that this API can be used on
> the main thread of an app. Exceptions can only be thrown synchronously
> which would mean that we have to block until the server has been
> successfully set up, which would lead to locked up UI. We have to use
> error events for anything that requires IO before knowing if it has
> succeeded or failed.
> 
> And whether we are using error events or exceptions, you still need to
> define exactly what the errors look like, so there's no difference in
> the work that needs to be done on the speccing side.

[Claes] I agree on what you say above and fulfilling this is my ambition. 

However, looking in the specification I see that for all three socket interfaces there is one situation for which I may have change the error handling from exception to error event. This is when the localAddress/localPort is already in use (for example by another application) and the addressReuse option is not set. 

If we change the error handling for "localAddress/localPort already in use" from exception to error event then we definitely need the "open" event for TCPServerSocket even though I am not sure that the internal activities on setting up the listener, e.g. checking if address/port is free, takes time. This will make the API slightly more complicated and will also apply to UDPSockets as far as I can see. 

So, as a summary:

* For UDPSocket and TCPServerSocket add an "open" event stating that socket has successfully been set up
* Use readyState "connecting" during the process of setting up the UDPSocket and TCPServerSocket but state in the description that this means just setting up the socket for UDPSocket and TCPServerSocket. Or maybe it is better to have separate readyState enums for UDP, TCP and TCPServer?
* Change the error handling for "localAddress/localPort already in use" from exception to using the "error" event.

In addition I will go through the specification and check the error handling.

Sounds ok?
> 
> / Jonas
> 
> >> / Jonas
> >>
> >> > Claes
> >> >
> >> >> -----Original Message-----
> >> >> From: Jonas Sicking [mailto:jonas@sicking.cc]
> >> >> Sent: den 12 maj 2013 03:52
> >> >> To: public-sysapps@w3.org
> >> >> Subject: Error handling for TCPServerSocket
> >> >>
> >> >> The error handling for TCPServerSocket is somewhat unclear.
> >> >>
> >> >> What errors can be raised if we fail to open the server? What
> >> >> errors can be fired once the server is successfully set up?
> >> >>
> >> >> And how does the caller know that the server has been
> successfully
> >> >> set up?
> >> >>
> >> >> / Jonas
> >> >

Received on Thursday, 16 May 2013 12:29:30 UTC