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

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

From: Nilsson, Claes1 <Claes1.Nilsson@sonymobile.com>
Date: Thu, 8 Aug 2013 09:47:49 +0200
To: 'Jonas Sicking' <jonas@sicking.cc>, Anne van Kesteren <annevk@annevk.nl>
CC: "www-dom@w3.org" <www-dom@w3.org>, "public-sysapps@w3.org" <public-sysapps@w3.org>
Message-ID: <6DFA1B20D858A14488A66D6EEDF26AA301A33878B427@seldmbx03.corpusers.net>
Thanks Jonas for informing me about the thread you started. Seems as a good approach to subclass DOMException to achieve a more granular error reporting when this is needed. So I'll keep the current construction until there is consensus on the solution in W3C and in the EcmaScript organization. 

BR
  Claes

> -----Original Message-----
> From: Jonas Sicking [mailto:jonas@sicking.cc]
> Sent: den 6 augusti 2013 21:51
> To: Anne van Kesteren
> Cc: Nilsson, Claes1; www-dom@w3.org; public-sysapps@w3.org
> Subject: Re: [DOMError]: Subclassing DOMError to increase granularity
> of error handling?
> 
> On Tue, Aug 6, 2013 at 2:53 AM, Anne van Kesteren <annevk@annevk.nl>
> wrote:
> > On Tue, Aug 6, 2013 at 10:24 AM, Nilsson, Claes1
> > <Claes1.Nilsson@sonymobile.com> wrote:
> >> WDYT about this approach? Is this a reasonable solution?
> >
> > DOMError is going away. We only need DOMException. Allen (editor of
> > ECMAScript) did suggest we do something like what you suggest. Have
> > DOMException.prototype.subname which gives a more detailed name and
> > ideally have DOMException.name be "DOMException" but we can probably
> > no longer do that. Still need to work out the details here
> > unfortunately as apparently last time we thought we figured error
> > handling out we didn't :/
> 
> Hi Claes,
> 
> In part based on our conversation for raw sockets, I started a thread
> on es-discuss about what patterns ES uses for error reporting. The
> threat can be read here:
> http://esdiscuss.org/topic/creating-your-own-errors
> 
> The outcome of that discussion was to change how the DOM does error
> reporting. Basically the outcome was to simply replace DOMError with
> DOMException. To then use a subclass of that for for example
> SocketError, and another subclass for AbortError. This would mean that
> the SocketError subclass could introduce additional properties to
> describe further details about the error.
> 
> Sounds like Allen didn't agree with the outcome of that thread.
> Instead, if I understand correctly, his proposal is that all errors
> reported by the DOM has .name="DOMException". Unfortunately that would
> not only make the DOM "go it's on way and not follow ES patterns", it
> would also make the DOM a second class citizen in the ES world since it
> would mean that it requires twice as much code to check an error
> reported by the DOM, as errors reported by ES and libraries.
> 
> So I don't think Allen's solution really is workable.
> 
> So yeah, I think lets stick with the current solution used in Raw
> Sockets until this issue is figured out.
> 
> / Jonas
Received on Thursday, 8 August 2013 07:48:19 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:36:14 UTC