Consistent error messages in all modules #892

micnic · 2015-02-19T15:50:07Z

This commit fixes some error messages that are not consistent with
some general rules which most of error messages follow.

cjihrig · 2015-02-19T15:54:35Z

lib/timers.js

 }

 if (msecs < 0 || !isFinite(msecs)) {
- throw new RangeError('msecs must be a non-negative finite number');
+ throw new RangeError('"msecs" argument must be a positive finite number');


"non-negative" and "positive" are not quite the same thing.

I used "positive" to fit in 80 characters line length, but I can switch it back

Probably best to split the string then.

cjihrig · 2015-02-19T15:56:42Z

I'm +1 on standardizing error messages. My only real question is, have we actually defined a standard for this? Based on this PR, it looks like it would be to capitalize at the beginning of the message, and to put argument names in double quotes.

piscisaureus · 2015-02-19T16:03:26Z

+1 on the idea of standardizing error messages.
Maybe it's good to discuss a template for them first?

Just a couple I run into:

Error: connect ENOENT does.not.exist
Error: getaddrinfo ENOTFOUND does.not.exist.com does.not.exist.com:81
Error: ENOENT: no such file or directory, open 'C:\Users\Bert Belder\bar\baz'
RangeError: port should be > 0 and < 65536: 0

silverwind · 2015-03-19T19:06:08Z

lib/smalloc.js

 if (Array.isArray(obj))
 throw new TypeError('Arrays are not supported');
 if (n > kMaxLength)
- throw new RangeError('n > kMaxLength');
+ throw new RangeError('"n" should be lesser than "kMaxLength"');


I think this should be "n" should be less or equal than "kMaxLength"

"less than or equal to"?

That's even better!

timoxley · 2015-03-19T20:26:12Z

Perhaps this is for another PR, but perhaps should make the usage of "should" vs "must" consistent – currently they seem to be used interchangeably:

e.g.

throw new TypeError('"options" argument must be an object');

vs

throw new TypeError('"curve" argument should be a string');

I'd suggest that once the code is throwing an assertion error it's out of the jurisdiction of a "should" and into the hands of "must", though perhaps "must" sounds a little pushy so perhaps io.js could optimise for developer feels and give people an illusion of choice with the calm & assertive "should".

Some related literature http://www.differencebetween.net/language/grammar-language/difference-between-should-and-must/

edit: I suggest following these common definitions used by RFCs in "Key word for use in RFCs to Indicate Requirement Levels": https://tools.ietf.org/html/rfc2119

bnoordhuis · 2015-03-20T15:50:54Z

I'm in favor of "must". Followed by "Or else."

/s

brendanashworth · 2015-03-24T00:38:57Z

lib/_http_outgoing.js

 if (value === undefined)
- throw new Error('`value` required in setHeader("' + name + '", value).');
+ throw new Error('"value" required in setHeader("' + name + '", value).');


required -> is required

I'd also say that we shouldn't replace "name" with the actual value of the variable

ronkorving · 2015-07-11T09:02:49Z

lib/_http_outgoing.js

@@ -307,9 +307,9 @@ function storeHeader(self, state, field, value) {

 OutgoingMessage.prototype.setHeader = function(name, value) {
 if (typeof name !== 'string')
- throw new TypeError('`name` should be a string in setHeader(name, value).');
+ throw new TypeError('"name" should be a string in setHeader(name, value).');


Nowhere (except in this file) do your error messages end with a period.

ronkorving · 2015-08-10T10:31:08Z

Is this still going places?

thefourtheye · 2015-08-10T11:36:27Z

Looks like this is favoured. Can you please rebase and address the comments?

This commit fixes some error messages that are not consistent with some general rules which most of error messages follow.

micnic · 2015-08-10T12:28:03Z

@thefourtheye, forgot about this PR, sorry :P
rebased and took in count all the comments added

Trott · 2015-08-10T17:32:09Z

LGTM if it passes CI. 👍

Maybe @nodejs/documentation can find an appropriate place for a minimal Error message standardization doc based on the existing error messages (if such a doc doesn't already exist). Just to get it off the ground, the doc might only contains the two things @cjihrig notes (double quotes, capitalize first word unless there's a compelling reason not to such as it is a case-sensitive variable name) along with a note about omitting final punctuation.

I would prefer a standard that had punctuation at the end and made verbs explicit (e.g., Index is out of range. rather than Index out of range) but consistency is way more important than my own somewhat arbitrary preferences.

thefourtheye · 2015-08-10T17:51:01Z

Hmmm, this should be targeted at master

r-52 · 2015-08-10T17:52:31Z

lib/crypto.js

@@ -515,7 +515,7 @@ DiffieHellman.prototype.setPrivateKey = function(key, encoding) {

 function ECDH(curve) {
 if (typeof curve !== 'string')
- throw new TypeError('curve should be a string');
+ throw new TypeError('"curve" argument should be a string');


Small question: Every other error is something line ".... must be ...". Does it make sense to change it also in crypto?

We don't have a compromise on this yet (should vs must) see https://tools.ietf.org/html/rfc2119

jasnell · 2015-10-14T18:38:02Z

@micnic ... in general this is a good step but it definitely needs to be targeted at master and rebased. It won't be able to land as is.

micnic · 2015-10-14T21:22:20Z

@jasnell, @thefourtheye, added #3374 I guess this PR can be closed

* Remove unneeded temp dir cleanup * Add check for error in `.close()` callback * Improve error reporting On that last bullet point, the previous version of the test reported errors like this: ``` AssertionError: [ '.empty-repl-history-file', '.node_repl_history', 'nodejsGH-1899-output.js', 'nodejsGH-892-request.js', 'a.js', 'a1.js', 'agen deepStrictEqual [ '.empty-repl-history-file', '.node_repl_history', 'nodejsGH-1899-output.js', 'nodejsGH-892-request.js', 'a.js', 'a1.js', 'agen ``` Now, they look like this: ``` AssertionError: 2a is hex value for * and not catch-stdout-error.js ```

* Remove unneeded temp dir cleanup * Add check for error in `.close()` callback * Improve error reporting On that last bullet point, the previous version of the test reported errors like this: ``` AssertionError: [ '.empty-repl-history-file', '.node_repl_history', 'nodejsGH-1899-output.js', 'nodejsGH-892-request.js', 'a.js', 'a1.js', 'agen deepStrictEqual [ '.empty-repl-history-file', '.node_repl_history', 'nodejsGH-1899-output.js', 'nodejsGH-892-request.js', 'a.js', 'a1.js', 'agen ``` Now, they look like this: ``` AssertionError: expected *, got ! by hex decoding 2a ``` PR-URL: nodejs#11232 Reviewed-By: James M Snell <jasnell@gmail.com>

* Remove unneeded temp dir cleanup * Add check for error in `.close()` callback * Improve error reporting On that last bullet point, the previous version of the test reported errors like this: ``` AssertionError: [ '.empty-repl-history-file', '.node_repl_history', 'GH-1899-output.js', 'GH-892-request.js', 'a.js', 'a1.js', 'agen deepStrictEqual [ '.empty-repl-history-file', '.node_repl_history', 'GH-1899-output.js', 'GH-892-request.js', 'a.js', 'a1.js', 'agen ``` Now, they look like this: ``` AssertionError: expected *, got ! by hex decoding 2a ``` PR-URL: #11232 Reviewed-By: James M Snell <jasnell@gmail.com>

* Remove unneeded temp dir cleanup * Add check for error in `.close()` callback * Improve error reporting On that last bullet point, the previous version of the test reported errors like this: ``` AssertionError: [ '.empty-repl-history-file', '.node_repl_history', 'nodejsGH-1899-output.js', 'nodejsGH-892-request.js', 'a.js', 'a1.js', 'agen deepStrictEqual [ '.empty-repl-history-file', '.node_repl_history', 'nodejsGH-1899-output.js', 'nodejsGH-892-request.js', 'a.js', 'a1.js', 'agen ``` Now, they look like this: ``` AssertionError: expected *, got ! by hex decoding 2a ``` PR-URL: nodejs#11232 Reviewed-By: James M Snell <jasnell@gmail.com>

PR-URL: nodejs#23513 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>

PR-URL: #23513 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>

cjihrig reviewed Feb 19, 2015
View reviewed changes

silverwind reviewed Mar 19, 2015
View reviewed changes

micnic mentioned this pull request Mar 20, 2015

Consistent error messages in all modules #1220

Closed

brendanashworth reviewed Mar 24, 2015
View reviewed changes

chrisdickinson added the land-on-master label Apr 17, 2015

ronkorving reviewed Jul 11, 2015
View reviewed changes

Consistent error messages in all modules

f28b73a

This commit fixes some error messages that are not consistent with some general rules which most of error messages follow.

r-52 reviewed Aug 10, 2015
View reviewed changes

micnic mentioned this pull request Oct 14, 2015

Consistent error messages in all modules #3374

Closed

micnic closed this Oct 14, 2015

codebytere mentioned this pull request Nov 27, 2018

v10.13.1 proposal #24675

Closed

codebytere mentioned this pull request Nov 29, 2018

v10.14.2 proposal #24727

Merged

snyk-bot mentioned this pull request Jan 31, 2022

[Snyk] Security upgrade shelljs from 0.7.8 to 0.8.5 enterstudio/node#26

Open

lpinca mentioned this pull request May 19, 2022

deps: upgrade to libuv 1.44.2 #42340

Closed

aliscco mentioned this pull request Apr 27, 2023

[Snyk] Fix for 30 vulnerabilities aliscco/alisco-node#279

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Consistent error messages in all modules #892

Consistent error messages in all modules #892

micnic commented Feb 19, 2015

cjihrig Feb 19, 2015

micnic Feb 19, 2015

silverwind Mar 19, 2015

cjihrig commented Feb 19, 2015

piscisaureus commented Feb 19, 2015

silverwind Mar 19, 2015

kenany Mar 19, 2015

silverwind Mar 19, 2015

timoxley commented Mar 19, 2015

bnoordhuis commented Mar 20, 2015

brendanashworth Mar 24, 2015

ronkorving Jul 11, 2015

ronkorving commented Aug 10, 2015

thefourtheye commented Aug 10, 2015

micnic commented Aug 10, 2015

Trott commented Aug 10, 2015

thefourtheye commented Aug 10, 2015

r-52 Aug 10, 2015

micnic Aug 10, 2015

jasnell commented Oct 14, 2015

micnic commented Oct 14, 2015

Consistent error messages in all modules #892

Consistent error messages in all modules #892

Conversation

micnic commented Feb 19, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cjihrig commented Feb 19, 2015

piscisaureus commented Feb 19, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

timoxley commented Mar 19, 2015

bnoordhuis commented Mar 20, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ronkorving commented Aug 10, 2015

thefourtheye commented Aug 10, 2015

micnic commented Aug 10, 2015

Trott commented Aug 10, 2015

thefourtheye commented Aug 10, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jasnell commented Oct 14, 2015

micnic commented Oct 14, 2015