-
Notifications
You must be signed in to change notification settings - Fork 27
Conversation
spec.html
Outdated
|
||
<emu-clause id="sec-aggregateerror-object-structure"> | ||
<h1>_AggregateError_ Object Structure</h1> | ||
<p>TODO</p> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
need help here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NativeError Object Structure description:
<p>When an ECMAScript implementation detects a runtime error, it throws a new instance of one of the _NativeError_ objects defined in <emu-xref href="#sec-native-error-types-used-in-this-standard"></emu-xref>. Each of these objects has the structure described below, differing only in the name used as the constructor name instead of _NativeError_, in the `name` property of the prototype object, and in the implementation-defined `message` property of the prototype object.</p>
<p>For each error object, references to _NativeError_ in the definition should be replaced with the appropriate error object name from <emu-xref href="#sec-native-error-types-used-in-this-standard"></emu-xref>.</p>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about something like:
<p>When an ECMAScript implementation detects a runtime error, it throws a new instance of one of the _NativeError_ objects defined in <emu-xref href="#sec-native-error-types-used-in-this-standard"></emu-xref> or a new instance of %AggregateError%. Each of these objects has the structure described below, differing only in the name used as the constructor name instead of _NativeError_, in the `name` property of the prototype object, in the implementation-defined `message` property of the prototype object, and in the presence of the %AggregateError%-specific `errors` property.</p>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NativeError Object Structure and AggregateError Object Structure are two separate sections so they need different descriptions
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I was thinking something like:
For NativeError
<p>When an ECMAScript implementation detects a runtime error, it throws either a new instance of one of the _NativeError_ objects defined in <emu-xref href="#sec-native-error-types-used-in-this-standard"></emu-xref> or a new instance of %AggregateError%. Each of the _NativeError_ objects has the structure described below, differing only in the name used as the constructor name instead of _NativeError_, in the `name` property of the prototype object, in the implementation-defined `message` property of the prototype object, and in the presence of the %AggregateError%-specific `errors` property.</p>
For AggregateError
<p>When an ECMAScript implementation detects a runtime error, it throws either a new instance of one of the _NativeError_ objects defined in <emu-xref href="#sec-native-error-types-used-in-this-standard"></emu-xref> or a new instance of %AggregateError%. Each _AggregateError_ object has the structure described below, differing only in the implementation-defined `message` property of the prototype object.</p>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've hoisted this to Error Objects decription
e6d18a0
to
79d9bf8
Compare
Co-Authored-By: Mathias Bynens <mathias@qiwi.be>
Co-Authored-By: Mathias Bynens <mathias@qiwi.be>
Co-Authored-By: Mathias Bynens <mathias@qiwi.be>
Co-Authored-By: Mathias Bynens <mathias@qiwi.be>
Co-Authored-By: Mathias Bynens <mathias@qiwi.be>
Co-Authored-By: Mathias Bynens <mathias@qiwi.be>
Co-Authored-By: Mathias Bynens <mathias@qiwi.be>
spec.html
Outdated
|
||
<emu-clause id="sec-aggregateerror-object-structure"> | ||
<h1>_AggregateError_ Object Structure</h1> | ||
<p>TODO</p> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about something like:
<p>When an ECMAScript implementation detects a runtime error, it throws a new instance of one of the _NativeError_ objects defined in <emu-xref href="#sec-native-error-types-used-in-this-standard"></emu-xref> or a new instance of %AggregateError%. Each of these objects has the structure described below, differing only in the name used as the constructor name instead of _NativeError_, in the `name` property of the prototype object, in the implementation-defined `message` property of the prototype object, and in the presence of the %AggregateError%-specific `errors` property.</p>
…section Co-Authored-By: Mathias Bynens <mathias@qiwi.be>
spec.html
Outdated
<emu-clause id="sec-error-objects"> | ||
<h1>Error Objects</h1> | ||
<p>Instances of Error objects are thrown as exceptions when runtime errors occur. The Error objects may also serve as base objects for user-defined exception classes.</p> | ||
<p>When an ECMAScript implementation detects a runtime error, it throws a new instance of one of the _NativeError_ objects defined in <emu-xref href="#sec-native-error-types-used-in-this-standard"></emu-xref> or a new instance of %AggregateError%. Each of these objects has the structure described below, differing only in the name used as the constructor name instead of _NativeError_, in the `name` property of the prototype object, in the implementation-defined `message` property of the prototype object, and in the presence of the %AggregateError%-specific `errors` property.</p> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why is aggregate error not just another one of the native error types?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, I’m not sure that suggestion is in fact the best solution - it ends up duplicating a lot of spec text. Is there a way we could modify the NativeError approach so it could handle AggregateErrors?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that it's possible. Will try to figure out
Co-Authored-By: Jordan Harband <ljharb@gmail.com>
Co-Authored-By: Jordan Harband <ljharb@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not a super big fan of leaving the NativeError magic in place when it won't work for all native errors - I'd prefer to see it handled in a more explicit way that also encompasses AggregateError.
</emu-clause> | ||
|
||
<emu-clause id="sec-aggregate-error.prototype.errors"> | ||
<h1>_AggregateError_.prototype.errors</h1> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
repeating: there must not be a mutable object data property on the prototype.
AggregateError.prototype.errors
must either be absent, a primitive, an accessor that returns a new array every time (either empty, or with the errors if #38 moves forward), or a data property using a frozen array.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should it be added to Properties of the _AggregateError_ Prototype Object
part?
Co-Authored-By: Jordan Harband <ljharb@gmail.com>
…al-promise-any into rest-of-aggregateerror
Just added "Native Error Types Used in This Standard" prose and Unfortunately, I won't have time for further changes until Monday :( |
15b2f1c
to
2fa9b4d
Compare
@mathiasbynens I've just updated |
spec.html
Outdated
1. Let _errorsNumString_ ! ToString(_errorsNum_). | ||
1. If _name_ is the empty String, return _msg_. | ||
1. If _msg_ is the empty String, return _name_. | ||
1. Return the string-concatenation of _name_, the code unit 0x003A (COLON), the code unit 0x0020 (SPACE), _msg_, "(", _errorsNumString_, " messages)". |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This results in "1 messages"
.
FWIW, I'd be totally okay with leaving this up to implementations, by making it part of the message
property. We could have a non-normative note that recommends implementers to include the message count in the error message.
Alright, let's merge this one soon. Any follow-up work can happen in separate PRs. Thanks, @chicoxyzzy! |
See #27 and #36
Unfinished parts:
AggregateError Object Structure descriptionI'm not sure how to update prose in 19.5.5 Native Error Types Used in This StandardAggregateError.prototype.toString