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 Tuesday, 6 August 2013 19:51:43 UTC