Repository navigation
errors.js module #14554
Description
Activity
Eventually this may be a possibility. For the time being, however, while we are still in the process of migrating all of our internal errors, I would rather avoid it. The reason is due to the fact that changes to that internal API are still possible / likely as we move along.
Reacted by Jeremiah Senkpiel and Ruben BridgewaterI think we can create a new module named
errors(better) or others.
errorsexportError/TypeError/RangeError/...just likeinternal/errorsexports.
And more,errorsexport a helper function to createErrorClasswith some type.
We assign a temp namemakeErrorto helper function.const PathNotFoundError = errors.makeError('ERR_PATH_NOT_FOUND', '%s not found') const err = new PathNotFoundError('/usr/foo/bar') // err.code === 'ERR_PATH_NOT_FOUND' // err.message === '/usr/foo/bar not found'
By the way, we can export all errors code used in
internal/errorstoerrors. Just likeerrors.ERR_ASSERTIONthat equals'ERR_ASSERTION'.
This can help user to check which error and don't need to remember code string.
String cannot autocompletion with IDE like WS, but exports variable can do.Reacted by Va Da and Alex YangI've opened an issue (#14216) and a PR (#14250) earlier before about separating the error codes to a new module, but the errors are still being migrated so they are blocked temporarily. IMHO, the appropriate time to do these is after the migration are done.
(But the migration is slower than I expected 😣 )just trying to understand what needs to be done here:
- make
internal/errors.jsexternal - make sure all the error classes are documented, if not already
is that so?
Reacted by Va Da and Alex Yang- make
There's been no activity on this issue for a long time. @nodejs/documentation, any update on this?
There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.
For more information on how the project manages feature requests, please consult the feature request management document.
Please keep this open.
There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.
For more information on how the project manages feature requests, please consult the feature request management document.
There has been no activity on this feature request and it is being closed. If you feel closing this issue is not the right thing to do, please leave a comment.
For more information on how the project manages feature requests, please consult the feature request management document.
Please re-open this (?)
This is such a useful feature, yet it's dead again
Jesus... I want to test for the type of error in my unit tests and it seems like a headache? What
Jesus... I want to test for the type of error in my unit tests and it seems like a headache? What
There is just no good way as far as I've looked. The only way I have ever found is to check if it's an instanceof Error and then check the .name property. It's horrid. I've ever only found pain when dealing with JS exceptions.
Node now has
internal/errors.jsmodule which allows to set static error codes for errors, which is great. Would be good to expose Node's internal error constructors in a new module sayrequire('errors').My use case is as follows: I am now rewriting an in-memory file system module
memfsthat mimics howfsmodule works, I would like to throw exactly the same errors as Node does, so that it can be used for testing, so now I have to basically copy-paste theinternal/errors.jsfile into my project to be able to create similar errors to what Node does.