Jonas Sicking (2013-07-17T18:10:55.000Z)
On Tue, Jul 16, 2013 at 5:05 PM, Erik Arvidsson
<erik.arvidsson at gmail.com> wrote:
> On Tue, Jul 16, 2013 at 4:30 PM, Jonas Sicking <jonas at sicking.cc> wrote:
>
>> Object.toString(x)
>
> I assume you mean Object.prototype.toString.call(x)
>
>> I *don't* think it's important what this returns. I.e. I would guess
>> that we can safely subclass DOMException as needed.
>>
>>
>> I think we have the following constraints for properties that contain
>> error information in APIs that currently use DOMError
>> (IDBTransaction.error in the IndexedDB spec for example).
>>
>> x instanceof DOMError
>> Probably doesn't matter what this returns.
>
> FWIW, Neither Blink nor WebKit exposes DOMError so this should be safe
> to change (on the open web at least).
>
>> x.name = "AbortError"
>> This should be uncontroversial enough that I don't think it matters
>> how much dependency there is, right?
>>
>> x.message
>> This probably needs to contain a human readable error message. This
>> should be uncontroversial enough that I don't think it matters how
>> much dependency there is, right?
>>
>> Object.toString(x)
>> Probably doesn't matter what this returns.
>>
>>
>> I doubt that in either case it matters if these properties live on the
>> objects themselves, or on the prototype chain.
>>
>>
>> So all in all, I think we have a lot of room for what to do in both
>> cases. The only requirements is that exceptions *likely* need to test
>> true for "instanceof DOMException", and that they in some cases need
>> to have a specific numeric code property.
>>
>> My recommendation would be to
>> * Get rid of DOMError and use DOMException in its place
>> * Add new subclasses for each exception type. I.e. exceptions with
>> .name == HierarchyRequestError should also test true for "instanceof
>> HierarchyRequestError"
>> * Keep specifying that DOMException is a subclass of Error. This is
>> already the case, but I wanted to make it clear that this shouldn't
>> change.
>>
>> I personally think that the second bullet is a bit silly. But since
>> that appears to be the convention that ES uses then we should stick
>> with it.
>
> Agreed.
>
> There will be issues here since DOM has throw a SyntaxError, which
> means throw a DOMException with the name SyntaxError and the code
> DOMException.SYNTAX_ERR so that would mean that we have a naming
> conflict since ES already have a SyntaxError constructor.

Good point. It's entirely plausible that we could simply use the ES
SyntaxError in all cases where DOMException SyntaxError is being
thrown today. Would need to be tested though.

/ Jonas
domenic at domenicdenicola.com (2013-07-19T15:58:06.266Z)
On Tue, Jul 16, 2013 at 5:05 PM, Erik Arvidsson <erik.arvidsson at gmail.com> wrote:
> There will be issues here since DOM has throw a `SyntaxError`, which
> means throw a `DOMException` with the name `SyntaxError` and the code
> `DOMException.SYNTAX_ERR` so that would mean that we have a naming
> conflict since ES already have a `SyntaxError` constructor.

Good point. It's entirely plausible that we could simply use the ES
`SyntaxError` in all cases where `DOMException` `SyntaxError` is being
thrown today. Would need to be tested though.