Repository navigation
Readonly error.code has ecosystem impact. #15658
Description
Activity
There was some discussion about that in the PR introducing internal/errors: #11220 (review)
/cc @jasnell
Yes, the read only was intentional in order to explicitly prevent blind overriding. I believe the property is still configurable tho. It's been a while tho so I may be wrong
Yes, the read only was intentional in order to explicitly prevent blind overriding.
This applies to CJS code as well, right?
Is there a user-land scenario in mind, around augmenting Node specific errors, that you're wanting to prevent?
I'm wondering if the user-land code should have to worry about it. To user-land code an error object is an error object. It could be a syntax error, or some other kind of error, and now code will have to branch for Node specific error objects or handle all error objects as tricky ones (which I'd assume is not the usual case).
Reacted by Rich Trott and Felix BeckerI'm not against changing it. There is a side effect in that the code is used in the name property, so it's not entirely free
There is a side effect in that the code is used in the name property, so it's not entirely free
The symbol prop is used in the
nameso.codeand.namecan be modified independently.I would be +1 on changing. I've seen usage of overwriting Error#code some.
Reacted by Anna Henningsen, Clinton Wood and Rich TrottWhat I mean is that changing code would make it out of sync with the name. We should decide whether those should be kept in sync automatically.
We should decide whether those should be kept in sync automatically
Since the
.codeand.nameprops aren't tied together (.namedoesn't rely on.code) I think it'd be fine to allow augmenting to be yolo (getting too fancy with syncing seems like unnecessary overhead).Reacted by Anna Henningsen, Clinton Wood, Rich Trott and Felix BeckerThat's the answer I'd be hoping for ;)
- added 2 commits that reference this issue
on Oct 12, 2017 - added 2 commits that reference this issue
on Oct 12, 2017 - added 2 commits that reference this issue
on Oct 23, 2017
I know internal/errors usage is picking up in Node core so I thought I'd give a heads up on something I've seen in the wild. It looks like folks are adding
error.codeproperties which will error with theinternal/errorssinceerror.codeis readonly.Is being readonly intentional?