Conflict with DOMException

[annevk]

I don't like this as DOMException has Error in its prototype chain so we'd end up shadowing this new property making it useless in a lot of web platform code.

The web platform has established a pattern whereby if the name field is not granular enough you create a subclass of DOMException for the domain in question with specific fields that make sense.

[jasnell]

It would only shadow in cases like DOMException where code has an established meaning. We're not changing DOMException here so this really wouldn't be web breaking. I'm not convinced this is a strong enough reason against this and I'm not convinced that we should be letting DOMException constrain language-level changes.

[annevk]

Why would it only shadow in those cases? code is always present.

And even then, in the vast majority of cases code returns a non-0 value.

[jasnell]

Code is always present on DOMException. But like cause, it's only installed as an own property on Error if it is passed as an option on construction, and DOMException does not pass it to the super(...).

[jasnell]

Based on the discussion we had at the plenary when the proposal was introduced, I believe we can mark this issue resolved. DOMException is not constrained in a backwards incompatible way by this and like cause, there is flexibility in how DOMException handles it.

[annevk]

I cannot reopen this, but I'm not satisfied. For cause we have a clear way forward how we can make that work with DOMException as outlined in whatwg/webidl#969 but not currently pursued. That's not the case here as code is already a thing for DOMException.

[ljharb]

class DOMException extends Error {
  constructor(msg, options = {}) {
    const { code, cause, ...superOpts } = options;
    super(msg, superOpts);
    // install cause and/or code as you like
  }
}

would that not work just fine, for this or any other property set by options?

[annevk]

I think it would require a pretty drastic change to https://webidl.spec.whatwg.org/#idl-DOMException as code could no longer be defined or implemented that way. Though for the majority of cases it would still have to behave exactly in the same way.

[ljharb]

I'm confused - Web IDL is just spec language, so i'm not sure why it'd ever constrain the implementation - if it ever does, you'd surely just change webidl?

[annevk]

In my experience we don't "just" break invariants established for decades.

[ljharb]

What runtime invariant are you concerned about breaking? (WebIDL only exists to drive the implementation, so I'm not sure why invariants there matter)

[jasnell]

I guess the thing that I'm unclear about is why DOMException has to care at all. It already has it's own notion of code whose value space is compatible. The only difference really is that it's a prototype property and not an own property, but that seems... ok... to me?

Just having new DOMException('...') that does not accept a code option in the constructor just wouldn't have the .code own property. Nothing say it can't have .code property at all and error.code just works in either case.

It's also clear that the ecosystem has already worked out ways to deal with these differences. Node.js error codes and DOMException codes coexist just fine.

[ljharb]

It would continue to have an own property either way, so I don't see any observable difference.

[jasnell]

code on a DOMException is a prototype property.

Object.getOwnPropertyDescriptor(domException, 'code'); // undefined

Object.getOwnPropertyDescriptor(Object.getPrototypeOf(domException), 'code'); // { ... }

The difference is observable, but I'm not convinced it is meaningful. A DOMException is already unique from Error, TypeError, etc. It's ok if it works differently.