W3C home > Mailing lists > Public > public-sysapps@w3.org > May 2013

RE: Error handling for TCPServerSocket

From: Nilsson, Claes1 <Claes1.Nilsson@sonymobile.com>
Date: Wed, 15 May 2013 13:36:23 +0200
To: 'Jonas Sicking' <jonas@sicking.cc>
CC: "public-sysapps@w3.org" <public-sysapps@w3.org>, "Edenbrandt, Anders" <Anders.Edenbrandt@sonymobile.com>, "Isberg, Anders" <Anders.Isberg@sonymobile.com>, "Isaksson, Björn" <Bjorn.Isaksson@sonymobile.com>
Message-ID: <6DFA1B20D858A14488A66D6EEDF26AA3010F4E5ACD2F@seldmbx03.corpusers.net>
Yes, I will add names of the DOMError generated in different situations.

BR
  Claes

> -----Original Message-----
> From: Jonas Sicking [mailto:jonas@sicking.cc]
> Sent: den 13 maj 2013 19:41
> 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 4:06 AM, Nilsson, Claes1
> <Claes1.Nilsson@sonymobile.com> wrote:
> > In addition, for errors that occurs after the socket has successfully
> been set up we already have the error event but we need to add that the
> event is not only fired when a new connection attempt to the TCP server
> socket cannot be served, but also when an error in the underlying layer
> occurs, e.g. network connection is lost.
> >
> > Would this be sufficient?
> 
> You also need to define what those events look like. I.e. what is
> the .name of the DOMError that they contain for the various error
> conditions that can occur here.
> 
> The use-case is wanting to create a UI which displays error messages to
> the user on the form of "We were unable to set up a server to listen
> for incoming chat requests. Perhaps you already have another <chat
> protocol name here> server running in another application. If so,
> please try closing that application and press the 'connect' button
> again".
> 
> For this to be possible the application needs to receive a machine-
> readable error which it can use to determine which error UI to display.
> 
> / Jonas
> 
> >> -----Original Message-----
> >> From: Nilsson, Claes1
> >> Sent: den 13 maj 2013 12:58
> >> To: 'Jonas Sicking'; public-sysapps@w3.org
> >> Cc: Edenbrandt, Anders; Isberg, Anders; Isaksson, Björn
> >> Subject: RE: Error handling for TCPServerSocket
> >>
> >> 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.
> >>
> >> 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?
> >>
> >> 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:52 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 1 July 2021 16:04:43 UTC