Re: [DOMError]: Subclassing DOMError to increase granularity of error handling?

* Anne van Kesteren wrote:
>On Thu, Aug 8, 2013 at 12:05 PM, Nilsson, Claes1
><Claes1.Nilsson@sonymobile.com> wrote:
>> This is not just for debugging. Looking at the example I give in
>> the mail, i.e. when the attempt to create a TCP socket fails I
>> expect the web application to handle each error situation ("no
>> network contact","peer does not respond", "local address/port
>> pair is already in use") differently.
>
>That seems somewhat unlikely to me, especially at such a low level.
>Typically when scripts are written the expectation is that it will
>work (and it's tested until it does) and maybe have some handling for
>when things fall apart, but certainly not wide and varied failure
>scenarios.

It would seem to me that this is about issues like a web server telling
the user why it cannot launch as configured (another server is already
listening on port 80, the user does not have sufficient privileges on
the system to listen on port 80) and other end-user facing issues. It's
quite necessary to give users a localised error message beyond "network
error" so they can adapt the application and system configuration to use
the application.

This can also take the form of directing the user to the relevant
configuration settings, e.g. an error message might link to the system
configuration menu where users can control the maximum number of TCP
ports that can be used simultaneously, or to an overview list of the
attached network devices and their assigned IP addresses if the user
tried to bind the server to a bad address.

The list of "Windows Sockets Error Codes" should be a good illustration
of what application developers would typically expect to have access to.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Monday, 12 August 2013 14:54:59 UTC