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

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:20 UTC