You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Allow errors (read: exceptions, Error instances) to propagate extra information with them upstream to their eventual endpoint.
Rational
When an error occurs it is sometimes possible to analyze the situation so that extra details about the error, which could be helpful to either the end user or players, may be generated. These extra details are not always suitable for inclusion directly within the error message—e.g., a suggested course of action.
Therefore, it is desirable to have a mechanism by which these extra details may be included with the error as it travels upstream towards its eventual endpoint. Said mechanism is similar to using the <Error>.cause property to provide structured data and could be used to implement this feature.
Suggestion
When extra details can be generated, assign a specifically constructed "details" object to <Error>.cause.
A possible example of the format of the "details" object:
code: Number or string ID representing the issue.
hint: Suggested resolution.
origin: Original exception, if any.
values: Data about the error—probably an array. Possibly closely tied to code, so the endpoint knows what to do with the data.
Potential issues
The <Error>.cause property debuted in most browsers in the latter half of 2021, so Error instances in older browser aren't going have it. This means that it will need to be added to Error instances in affected browsers. Adding expando properties to JavaScript natives is generally frowned upon, however, it has been, and occasionally still is, done for various reasons, some good, and presents no real danger in this instance. This is not a blocker.
The text was updated successfully, but these errors were encountered:
Allow errors (read: exceptions,
Error
instances) to propagate extra information with them upstream to their eventual endpoint.Rational
When an error occurs it is sometimes possible to analyze the situation so that extra details about the error, which could be helpful to either the end user or players, may be generated. These extra details are not always suitable for inclusion directly within the error message—e.g., a suggested course of action.
Therefore, it is desirable to have a mechanism by which these extra details may be included with the error as it travels upstream towards its eventual endpoint. Said mechanism is similar to using the
<Error>.cause
property to provide structured data and could be used to implement this feature.Suggestion
When extra details can be generated, assign a specifically constructed "details" object to
<Error>.cause
.A possible example of the format of the "details" object:
code
: Number or string ID representing the issue.hint
: Suggested resolution.origin
: Original exception, if any.values
: Data about the error—probably an array. Possibly closely tied tocode
, so the endpoint knows what to do with the data.Potential issues
The
<Error>.cause
property debuted in most browsers in the latter half of 2021, soError
instances in older browser aren't going have it. This means that it will need to be added toError
instances in affected browsers. Adding expando properties to JavaScript natives is generally frowned upon, however, it has been, and occasionally still is, done for various reasons, some good, and presents no real danger in this instance. This is not a blocker.The text was updated successfully, but these errors were encountered: