Consistent error messages in all modules

[micnic]

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

[Fishrock123]

Can these be linted somehow? cc @Trott and @silverwind?

[cjihrig]

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.

[silverwind]

I'm sure they can. How about something like this?

1. Start with uppercase or double quote.
2. Always end in a dot.
3. Quotes must be balanced.
4. Warn on ' and backticks.

Rule 2 is inconsistent in this PR, btw. But we could also omit the dot. Which style is prefered?

[mscdex]

Warning on ' could be annoying, forcing everyone to not use contractions :-)

[silverwind]

Can we include a period at the end of all messages? They are full sentences after all.

[Trott]

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.

[micnic]

@silverwind not all of them are sentences, for example bad argumenthttps://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

[silverwind]

Fine with me. Go ahead and remove those periods.

[micnic]

Updated the PR to have no periods at the end of error messages.

[silverwind]

LGTM. Are we fine with landing this as a patch? I don't suppose we count error messages as part of the API?

[silverwind]

I think this conflicts with #3100.

I'd land this as a patch if no one objects, @micnic can we get a rebase?

[micnic]

@silverwind done

[silverwind]

Thanks! Landed in 20285ad.

[cjihrig]

Was this landed without running CI? I'm seeing a number of tests failing that depend on the value of the error message.

[cjihrig]

Working on a fix

[silverwind]

Looks like it, sorry about that.

[mikeal]

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.

[evanlucas]

This could even be semver-major IMO. People could have tests or code that rely on these error messages...

[mikeal]

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.

[silverwind]

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]

Marked as minor, even thought it doesn't exactly qualify as a feature.

[silverwind]

Tagged this and #3727 as semver-major as per #3776.