Node: Consistent `TypeError`s

Created on 3 Aug 2017  路  4Comments  路  Source: nodejs/node

fs.readFileSync(null)
// > TypeError: path must be a string or Buffer

path.join(null)
// > TypeError: Path must be a string. Received null

new URL(null)
// > TypeError [ERR_INVALID_URL]: Invalid URL: null

The above output is from Node.js v8.2.1. I think It would be nice if TypeErrors in general would be more consistent across Node.js鈥檚 core modules.

errors question

Most helpful comment

Looking at changes thus far in 9.0.0-pre, it does seem like the ERR_INVALID_URL (from new URL(null)) above might be better as ERR_INVALID_ARG_TYPE (which is what path.join(null) throws). I would expect ERR_INVALID_URL if I passed a string that wasn't a valid URL. But passting null is different. Not sure if it should be changed or not--there may be performance considerations etc.--but flagging it now just in case.

All 4 comments

That's the eventual goal. All errors are being more standardized to include error codes and such. It takes time to convert entire modules over and doing so (currently) still is a semver-major change, meaning those incremental changes won't be seen until the next major version of node.

Thanks for the quick reply. I read about the standardization of error codes in the Node.js v8 blog post and am glad to hear that the error messages themselves will be revised eventually, too 馃憤

Looking at changes thus far in 9.0.0-pre, it does seem like the ERR_INVALID_URL (from new URL(null)) above might be better as ERR_INVALID_ARG_TYPE (which is what path.join(null) throws). I would expect ERR_INVALID_URL if I passed a string that wasn't a valid URL. But passting null is different. Not sure if it should be changed or not--there may be performance considerations etc.--but flagging it now just in case.

Looks like this has been answered. I'll close it out.

Was this page helpful?
0 / 5 - 0 ratings