Standard: Code output #176

New Issue

2020-08-21T04:05:39+02:00

Kreyren commented

2020-08-21 04:05:39 +02:00

(Migrated from github.com)

We are expecting you to write the code to return a user-friendly messages so that the error can be actually used as helpful tool for diagnostics and to avoid confusion of the end-users.

for example in simplified scenario:

rm something

Returns rm: cannot remove 'something': No such file or directory which may not be understandable by regular users thus we are expecting:

die() {
	case "$1" in
		*) printf 'FATAL: %s\n' "$2"
	esac

	exit "$1"
}

rm something || die 1 "Unable to remove a file 'something'"

Which returns:

rm: cannot remove 'something': No such file or directory
FATAL: Unable to remove a file 'something'

You should do your best to avoid contact with the end-user at all cost when it's in terms of diagnostics where you are expected to know what the issue is just from the output. If you are not able to do that then it's considered a bug that might require adding more logging in the code.
This is done to make the debugging of the code that failed in the wild more efficient since end-users or end-user's computer might lie (willingly or unwillingly), but your code is expected to be more trustworthy in that case.

Note that this is not an excuse to not provide the required support for your code so that it can be used by the community.

We are expecting you to write the code to return a user-friendly messages so that the error can be actually used as helpful tool for diagnostics and to avoid confusion of the end-users. for example in simplified scenario: ```sh rm something ``` Returns `rm: cannot remove 'something': No such file or directory` which may not be understandable by regular users thus we are expecting: ```sh die() { case "$1" in *) printf 'FATAL: %s\n' "$2" esac exit "$1" } rm something || die 1 "Unable to remove a file 'something'" ``` Which returns: `rm: cannot remove 'something': No such file or directory` `FATAL: Unable to remove a file 'something'` You should do your best to avoid contact with the end-user at all cost when it's in terms of diagnostics where you are expected to know what the issue is just from the output. If you are not able to do that then it's considered a bug that might require adding more logging in the code. This is done to make the debugging of the code that failed in the wild more efficient since end-users or end-user's computer might lie (willingly or unwillingly), but your code is expected to be more trustworthy in that case. Note that this is not an excuse to not provide the required support for your code so that it can be used by the community.

issue-label-bot[bot] commented

2020-08-21 04:05:41 +02:00

(Migrated from github.com)

Issue-Label Bot is automatically applying the label feature_request to this issue, with a confidence of 0.88. Please mark this comment with 👍 or 👎 to give our bot feedback!

Links: app homepage, dashboard and code for this bot.

Issue-Label Bot is automatically applying the label `feature_request` to this issue, with a confidence of 0.88. Please mark this comment with :thumbsup: or :thumbsdown: to give our bot feedback! Links: [app homepage](https://github.com/marketplace/issue-label-bot), [dashboard](https://mlbot.net/data/RXT0112/Zernit) and [code](https://github.com/hamelsmu/MLapp) for this bot.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: kreyren/Zernit#176