Consistent error messages in all modules #3374
Conversation
|
Can these be linted somehow? cc @Trott and @silverwind? |
|
I think we would have to have some very specific, well defined rules in order to lint natural language. I'm not sure that we ever established rules in #892. This is definitely a step in the right direction IMO though. |
|
I'm sure they can. How about something like this?
Rule 2 is inconsistent in this PR, btw. But we could also omit the dot. Which style is prefered? |
|
Warning on |
| @@ -92,7 +92,7 @@ OutgoingMessage.prototype.setTimeout = function(msecs, callback) { | |||
|
|
|||
| if (callback) { | |||
| if (typeof callback !== 'function') | |||
| throw new TypeError('callback must be a function'); | |||
| throw new TypeError('"callback" must be a function'); | |||
There was a problem hiding this comment.
Can we include a period at the end of all messages? They are full sentences after all.
There was a problem hiding this comment.
On the one hand, yes, they are complete sentences.
On the other hand, this is a typical usage:
try {
// whatever
} catch (e) {
console.error('Error "' + e.message +'" received while trying to foo.");
}
I can go either way, but agree that whatever is decided, it should be consistent.
There was a problem hiding this comment.
@silverwind not all of them are sentences, for example bad argument https://github.com/nodejs/node/pull/3374/files#diff-9a205ef7ee967ee32efee02e58b3482dR1965
I would propose to go without period at the end as this rule can be applied to all cases
There was a problem hiding this comment.
Fine with me. Go ahead and remove those periods.
|
Updated the PR to have no periods at the end of error messages. |
|
LGTM. Are we fine with landing this as a |
This commit fixes some error messages that are not consistent with some general rules which most of the error messages follow
|
@silverwind done |
This commit fixes some error messages that are not consistent with some general rules which most of the error messages follow. PR-URL: #3374 Reviewed-By: Roman Reiss <[email protected]>
|
Thanks! Landed in 20285ad. |
|
Was this landed without running CI? I'm seeing a number of tests failing that depend on the value of the error message. |
|
Working on a fix |
|
Looks like it, sorry about that. |
|
I think this should be semver-minor. We're going to see a ton of tests in modules break because of these formatting changes, as we've seen in other releases based on similar changes in libuv. We should also probably not take this in LTS for the same reason. |
|
This could even be semver-major IMO. People could have tests or code that rely on these error messages... |
|
We established some time back that "breaking tests" !== "breaking code/changes." The exact text of an error message is no guaranteed by the API, only that an error will exist (or throw). This is a perfect example, while some tests may break the code those tests are testing is not actually broken by the change. |
|
Yeah, probably best to not have it in LTS. While I'd consider error code and error type to be part of the API, error messages are kind of a grey zone. Not sure it fits the minor label, but feel free to add it @mikeal. |
silverwind
added
the
semver-minor
|
Marked as |
silverwind
added
semver-major
This commit fixes some error messages that are not consistent with some general rules which most of the error messages follow.
This is an updated PR for master branch, which is based on the PR #892 and the discussion in #1220