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.

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

/ 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 Wednesday, 15 May 2013 22:52:09 UTC