FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

Consistent error messages in all modules by micnic · Pull Request #3374 · nodejs/node · GitHub

/ node Public

Consistent error messages in all modules - #3374

Closed
micnic wants to merge 1 commit into
nodejs:masterfrom
micnic:master
Closed

Consistent error messages in all modules#3374
micnic wants to merge 1 commit into
nodejs:masterfrom
micnic:master

Conversation

micnic commented Oct 14, 2015

Copy link
Copy Markdown
Contributor

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

Copy link
Copy Markdown
Contributor

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

cjihrig commented Oct 14, 2015

Copy link
Copy Markdown
Contributor

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.

Copy link
Copy Markdown
Contributor

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 commented Oct 14, 2015

Copy link
Copy Markdown
Contributor

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

Comment thread lib/_http_outgoing.js Outdated

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

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

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

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.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

@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

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

Fine with me. Go ahead and remove those periods.

micnic commented Oct 19, 2015

Copy link
Copy Markdown
Contributor Author

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

Copy link
Copy Markdown
Contributor

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

Copy link
Copy Markdown
Contributor

I think this conflicts with #3100.

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

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

micnic commented Nov 9, 2015

Copy link
Copy Markdown
Contributor Author

@silverwind done

micnic added a commit that referenced this pull request Nov 9, 2015
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 <me@silverwind.io>

Copy link
Copy Markdown
Contributor

Thanks! Landed in 20285ad.

silverwind closed this Nov 9, 2015

cjihrig commented Nov 9, 2015

Copy link
Copy Markdown
Contributor

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

cjihrig commented Nov 9, 2015

Copy link
Copy Markdown
Contributor

Working on a fix

Copy link
Copy Markdown
Contributor

Looks like it, sorry about that.

mikeal commented Nov 9, 2015

Copy link
Copy Markdown
Contributor

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.

Copy link
Copy Markdown
Contributor

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

mikeal commented Nov 9, 2015

Copy link
Copy Markdown
Contributor

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.

Copy link
Copy Markdown
Contributor

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 PRs that contain new features and should be released in the next minor version. label Nov 10, 2015

Copy link
Copy Markdown
Contributor

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

silverwind added semver-major PRs that contain breaking changes and should be released in the next major version. and removed semver-minor PRs that contain new features and should be released in the next minor version. labels Nov 12, 2015

Copy link
Copy Markdown
Contributor

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

jasnell mentioned this pull request Mar 17, 2016
reconbot added a commit to serialport/node-serialport that referenced this pull request Nov 5, 2016
reconbot added a commit to serialport/node-serialport that referenced this pull request Nov 5, 2016
reconbot added a commit to serialport/utilities that referenced this pull request Mar 9, 2018
reconbot added a commit to serialport/node-serialport that referenced this pull request Jul 24, 2018
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

semver-major PRs that contain breaking changes and should be released in the next major version.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants


Back | FazBrowse Home | New Git URL