Reserving error options for future use?
rauschma opened this issue · comments
It may make sense to reserve error options for future use so that they don’t conflict with libraries – for example:
- All error options that start with lowercase letters must not be used by libraries.
What libraries?
- Node.js and browsers: node-common-errors
- Node.js only: node-verror
- Node.js only: composite-error
Some of these may use or may want to use an options object.
Sure, but I’m not sure why that would affect native Error objects - those packages have their own APIs and can adapt the options as needed to be compatible with native Errors (ie, to provide the only option that exists instead of blindly passing things through).
Good point. But it would still be nice if the sets of names were disjoint, then built-in properties could always be passed on and there wouldn’t be any name clashes in the future.
Related: Some existing libraries are already using the property .cause. These won’t be compatible with the new proposed feature and there is no easy fix.
The spec can’t mandate anything on libraries anyways, so I’m not sure what there is to do, except file an issue on each one and ask for the constraint you want.
My point is: Will there be more options/properties like .cause in the future?
- If not, there’s nothing to do.
- If yes, it may make sense to prepare for that.
Yes, probably, but I’m not sure what prep we can do. The spec constrains engines, not libraries or users.
Will there be more options/properties like
.causein the future?
I'd believe the answer will be yes. Like other built-in objects like Array, new features are gradually been adopted. And people will always have to do feature tests unless they are 100% sure the environment is supporting them. In the error properties case, the cause property can be arbitrary JavaScript values, that's been said, I don't get the point that existing libraries are not compliant with the spec, even if they are defining the cause as a method.
Some existing libraries are already using the property
.cause. These won’t be compatible with the new proposed feature and there is no easy fix.
Existing libraries that asserting error.cause as a function should already do a type guard or they are already broken from the very beginning. So as far as I could tell, the new spec will not break them by any means. If you encountered any incompatibility, I'd be very grateful if you can share the case with us.
Closing as there is no open question. Feel free to re-open if needed.