standard way to ignore an error
See original GitHub issueThis is mostly just a discussion item rather than a serious issue.
Currently standard
uses handle-callback-err which complains if you do not “handle” callback errors.
Sometimes you do want to not handle an error e.g. ignore mkdirp
errors.
The current rule is good as it encourages you to explicitly flag intentionally ignored errors rather than just leaving the future reader wondering whether the error was left ignored accidentally or for some purpose.
Even prior to using standard, I try to always flag explicitly ignored errors with a comment like so
mkdirp('/dir/might/exist', err => {
// ignore error
doStuff()
})
This only changed slightly upon starting to use standard:
mkdirp('/dir/might/exist', err => {
err // ignore error
})
try {
mkdirp.sync('/dir/might/exist')
} catch (err) {
err // ignore err
}
Another option could be to use a different variable name for ignored errors:
mkdirp('/dir/might/exist', ignoreErr => {
doStuff()
})
Does anyone else have a standard pattern they use for flagging “ignored” errors?
It’s a possibility that even with the comment this is still a crappy workaround and I really should be explicitly whitelisting the error.code === 'EEXIST'
case and throw err
/return callback(err)
otherwise.
Note that it’s also still valid to not add any comment, which makes it again unclear whether the error is being ignored intentionally or not:
mkdirp('/dir/might/exist', err => {
err
doStuff()
})
This should perhaps be disallowed.
In fact, I’m not sure there’s any valid reason for a statement to solely contain a reference to a variable like that since it’s a noop so perhaps I’m really requesting a rule for something like “no useless statements”.
Issue Analytics
- State:
- Created 7 years ago
- Comments:6 (6 by maintainers)
Yeah,
_
is a nice solution. That’s what I use. But this is a pretty rare occurrence.Closing, since discussion has concluded 😄