Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve consistency of error message wordings #722

Merged
merged 1 commit into from
Nov 7, 2023

Conversation

edmorley
Copy link
Member

@edmorley edmorley commented Nov 7, 2023

  • Use contractions per Simplified Technical English guidelines (e.g. "Couldn't" instead of "Could not").
  • Prefer using past tense for potentially transient failures (e.g. "Couldn't read buildpack.toml" rather than "Can't").
  • Prefer using actual filenames rather than their spec names (e.g. "Couldn't read buildpack.toml" rather than "Couldn't read buildpack descriptor").
  • Use "I/O error" instead of "IO error" or "IOError"
  • Use display representations when including underlying error messages in the current error message where possible (ie: For most errors apart from io::Error). This also means preferring panic! over .expect(), since the latter uses the debug representation instead of display.
  • Use "Error ..." as the prefix for all top level error message (i.e. at the panic! or .expect() call sites).
  • Use #[error(transparent)] instead of #[error("{0}")] per: Fix error messages for buildpack packaging failures #720 (comment)

GUS-W-14445374.

* Use contractions per Simplified Technical English guidelines
  (e.g. "Couldn't" instead of "Could not").
* Prefer using past tense for potentially transient failures
  (e.g. "Couldn't read buildpack.toml" rather than "Can't").
* Prefer using actual filenames rather than their spec names
  (e.g. "Couldn't read buildpack.toml" rather than
  "Couldn't read buildpack descriptor").
* Use "I/O error" instead of "IO error" or "IOError"
* Use display representations when including underlying error
  messages in the current error message where possible (ie: For
  most errors apart from `io::Error`). This also means preferring
  `panic!` over `.expect()`, since the latter uses the debug
  representation instead of display.
* Use "Error ..." as the prefix for all top level error message
  (i.e. at the `panic!` or `.expect()` call sites).
* Use `#[error(transparent)]` instead of `#[error("{0}")]` per:
  #720 (comment)

GUS-W-14445374.
@edmorley edmorley force-pushed the edmorley/standardise-error-messages branch from 69f6026 to d5129b0 Compare November 7, 2023 12:53
@edmorley edmorley marked this pull request as ready for review November 7, 2023 13:04
@edmorley edmorley requested a review from a team as a code owner November 7, 2023 13:04
libcnb-test/src/test_runner.rs Show resolved Hide resolved
@edmorley edmorley merged commit 4ec39b6 into main Nov 7, 2023
4 checks passed
@edmorley edmorley deleted the edmorley/standardise-error-messages branch November 7, 2023 13:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants