Document AggregateError: errors

[sideshowbarker]

Fixes #7106

---

This one is exceptional in that the errors property is not a property of the prototype but is instead dynamically created on instantiation of the AggregateError object. See step 5 of the algorithm in the spec at https://tc39.es/ecma262/multipage/fundamental-objects.html#sec-aggregate-error

A precedent here is RegExp: lastIndex https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/RegExp/lastIndex, which we discussed in #2725.

Note also: this PR doesn’t add a separate new article for AggregateError: errors but intentionally just documents it in the AggregateError article itself. There’s really not a whole lot more which needs to be said that would justify a separate article.

(And the AggregateError.prototype.message and AggregateError.prototype.name links aren’t actually to separate articles specific to AggregateError, but instead just redirect to the Error.prototype.message and Error.prototype.name articles.)

[github-actions]

Preview URLs

• https://pr7116.content.dev.mdn.mozit.cloud/en-US/docs/Web/JavaScript/Reference/Global_Objects/AggregateError

Flaws

None! 🎉

External URLs

URL: /en-US/docs/Web/JavaScript/Reference/Global_Objects/AggregateError
Title: AggregateError
on GitHub

No new external URLs

[Elchi3]

I just reviewed this using the markdown rich diff in the GitHub UI and it is sooo nice! 😢😢😢
This is the future, great stuff! 👍

[InExtremaRes]

@sideshowbarker Thank you.

I'm somewhat late but, do you think that could be important to specify that the property is writable, non-enumerable and the array is also mutable for a given instance (i.e. not frozen or similar)? I remember seeing a very long discussion in the proposal regarding this property and if the array should be frozen, if a brand new array should be returned every time, if a new internal slot should be accessed, etc. So I guess those aren't obvious and someone could expect some behaviour it doesn't have.

And BTW, doesn't message work more or less that way as well? For what I understand from https://tc39.es/ecma262/multipage/fundamental-objects.html#sec-error-message (and other Error's constructors, as AggregateError) the constructor defines the property in the instance, but only if a message is passed to the constructor, in which case there is also an own, non-enumerable, mutable property in the instance.

[sideshowbarker]

do you think that could be important to specify that the property is writable, non-enumerable and the array is also mutable for a given instance (i.e. not frozen or similar)?

Yeah, that seems like useful information to add. Would you be interested in writing up a PR for it?

doesn't message work more or less that way as well? For what I understand from tc39.es/ecma262/multipage/fundamental-objects.html#sec-error-message (and other Error's constructors, as AggregateError) the constructor defines the property in the instance, but only if a message is passed to the constructor, in which case there is also an own, non-enumerable, mutable property in the instance

Yeah, that all sounds right (though without testing it or going back and reading the spec, I’m not certain)