W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2013

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

From: Nilsson, Claes1 <Claes1.Nilsson@sonymobile.com>
Date: Tue, 6 Aug 2013 11:24:14 +0200
To: "'www-dom@w3.org'" <www-dom@w3.org>
CC: "public-sysapps@w3.org" <public-sysapps@w3.org>
Message-ID: <6DFA1B20D858A14488A66D6EEDF26AA301A33878B421@seldmbx03.corpusers.net>
Dear DOM experts,

I am a member of the System Applications WG and editor for the Raw Socket API specification, http://www.w3.org/2012/sysapps/raw-sockets/.

We have had a discussion on error handling, https://github.com/sysapps/raw-sockets/issues/18.

The basic problem with error handling is that with the standard DOMError interface the granularity of machine readable error names are too limited. An example is when the attempt to create a TCP socket fails. The reason can for example be "no network contact"," peer does not respond" and "local address/port pair is already in use". The available DOM error names does not make it possible to separate these error reasons and the only sensible error name for all these situations is "NetworkError".

I assume that this is a problem that can apply to other specifications as well.

The approach I have taken in the Raw Socket API is a subclass of DOMError called SocketError that adds an attribute "type" that details the error in addition to the error names defined for DOMError.

WDYT about this approach? Is this a reasonable solution?

Best regards

Claes Nilsson M.Sc.E.E
Master Engineer - Web Research
Advanced Application Labs

Sony Mobile Communications
Tel: +46 705 56 68 78


(image/jpeg attachment: image001.jpg)

Received on Tuesday, 6 August 2013 09:25:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:37:03 UTC