RE: Error handling for TCPServerSocket

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.
> 
> > 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 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. So if the execution of the constructor is successful, i.e. no exception is issued, the application starts listening for connect events and error events. The description of the handling of error events in the specification must be extended to support not only failed client connection attempts but also general errors with this TCPServerSocket, e.g. network connection lost. So my point is that the application must handle the error event irrespective on when it is generated, shortly after the TCPServerSocket constructor has been called (for example when there is no network connection at the time of calling the constructor and it takes some time to detect that) or later (for example when the previous running network connection is lost).

 
> 
> / 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 Wednesday, 15 May 2013 11:36:47 UTC