Normative: remove the [[ErrorData]] internal slot

[domenic]

This replaces the [[ErrorData]] internal slot, which is only used for
brand-checking in Object.prototype.toString, with @@toStringTag. This
lets errors be simple objects with no extra private data, just as if
they were implemented in JavaScript code.

This observably changes the behavior of Error instances with
@@toStringTag modified or shadowed.

---

Presumably this needs consensus. We can bring it up at the next meeting.

[domenic]

Hmm. I just realized this might be a bad idea after all.

We have a feature request in HTML to make error objects structured-cloneable: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28389. But after this change, there would be no way for HTML to detect an error object (no brand for it to check), and thus it would try to serialize it as an ordinary object. The structured clone algorithm ignores non-enumerable properties, which error.name and error.message are (not to mention error.stack). So after this change errors would just structured clone as an empty object.

I guess the alternative for HTML would be to do what we advise authors to do, and avoid the nominal brand checking in favor of something like InstanceofOperator(object, %Error%). That does seem reasonable to me.

[ljharb]

One great way to detect an error object is Error.isError :-p I've found more concrete use cases for it (tc39/proposal-is-error#2) so I'll be revisiting this in March - and the internal slot will be needed for that if isError gets consensus.

[domenic]

As you know, I oppose that proposal. So I guess we will indeed discuss this all in March.

[claudepache]

Does it still make sense to say "It is not an Error instance", now that everything is an ordinary object?

[domenic]

I think it makes as much sense as any of the other "Is not an X instance" statements. Presumably they are all combating the same misconception from ES3 days that the prototype is some kind of exemplar of the type. I don't see why this change would impact things.

[erights]

https://esdiscuss.org/topic/error-stack-strawman is a thread about introducing api for obtaining stacks from errors. This would need to add new internal state to error objects anyway, making them detectably different. So any simplicity gain we make from making errors really just be plain objects is likely short lived.

[annevk]

Yeah, and implementations likely have internal slots anyway to store data that can be exposed to consoles but not the web.

[domenic]

Per March TC39 discussion, I still think this is a good idea, but it won't make errors non-exotic because of the [[StackData]] internal slots that @erights will be proposing. It might be best to wait until after that lands to continue to propose this, since otherwise errors will appear non-exotic in the spec even though they aren't in reality.

[bterlson]

Going to close this for now. @eright's proposal supercedes here I think, and I'm not too eager to make changes in advance of that lest we make things harder on ourselves. Status quo, for now.

[erights]

@erights ' and @ljharb 's proposal that is. Thanks.