[sysapps/raw socket api]: Error handling

Hi Jonas,

Based on https://github.com/sysapps/raw-sockets/issues/18 and our mail dialogue on error handling I have created a subclass of DOMError called  SocketError<http://www.w3.org/2012/sysapps/raw-sockets/#idl-def-SocketError>
that has the attribute type, which is an enum stating the detailed reason for the error. WDYT? Should we contact the WebApps WG to hear their option on this approach? If so, do you (or anyone else) know if www-dom@w3.org<mailto:www-dom@w3.org?subject=%5Bdom%5D%20> is the correct address for a question on this?

Background for all:

The background is a mail dialogue between me and Jonas:
http://lists.w3.org/Archives/Public/public-sysapps/2013Jul/0008.html
http://lists.w3.org/Archives/Public/public-sysapps/2013Jul/0017.html
http://lists.w3.org/Archives/Public/public-sysapps/2013Jul/0020.html

So, 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".

In the previous version of the specification I tried to solve this problem by distinguishing between these error reasons with the DOMError message attribute. However, the message attribute contains an implementation dependent message to be displayed to the user. Using this attribute does not make machine readable handling of errors possible, i.e. the application can not be coded to handle these dirrent error reasons in different manners.

The http://darobin.github.io/api-design-cookbook/ does not give much guidance here. So after discussion with Jonas I took the approach of subclassing DOMError and added the "type" attribute that provides a more detailed error definition than the "name" attribute.

This problem with error handling is probably applicable for more W3C specifications and it would be good if the authors of the DOM-specification stated a recommended approach on how to define a more granular error handling.

Best regards
  Claes


Claes Nilsson M.Sc.E.E <mailto:www-dom@w3.org?subject=%5Bdom%5D%20>
Master Engineer - Web Research <mailto:www-dom@w3.org?subject=%5Bdom%5D%20>
Advanced Application Labs<mailto:www-dom@w3.org?subject=%5Bdom%5D%20>
 <mailto:www-dom@w3.org?subject=%5Bdom%5D%20>
Sony Mobile Communications<mailto:www-dom@w3.org?subject=%5Bdom%5D%20>
Tel: +46 705 56 68 78<mailto:www-dom@w3.org?subject=%5Bdom%5D%20>
sonymobile.com<mailto:www-dom@w3.org?subject=%5Bdom%5D%20>
 <http://sonymobile.com/>
[cid:image001.jpg@01CE7965.C33E9780]<http://sonymobile.com/>