Improve description of Error Handling exercise

[rsp]

This is the 3rd simplest exercise (after Hello World and Two Fer) but it is not clear what are the requirements, which might discourage someone from learning Bash.

Currently the entire description displayed is:

Instructions
Implement various kinds of error handling and resource management.

An important point of programming is how to handle errors and close resources even if errors occur.

This exercise requires you to handle various errors. Because error handling is rather programming language specific you'll have to refer to the tests for your track to see what's exactly required.

Bash-specific instructions
The goal of this exercise is to consider the number of arguments passed to your program. If there is exactly one argument, print a greeting message. Otherwise print an error message and exit with a non-zero status.

It is not clear that:

• The argument is a person's name and must be used in the greeting
• The greeting must have a form of "Hello, $name"
• The empty string argument must result in "Hello, " instead of treating as missing argument
• The error message for wrong number of arguments must be exactly "Usage: error_handling.sh <person>"

As it currently is, one might thing that e.g. printing "Hey" and "Error" should be ok, and then only by analyzing the test error messages understand what the task is really all about. If someone is not already experienced in Bash, this might be discouraging so I think it would be nice if it was clear what exactly the program is expected to do.

👋 Btw, this is my first PR here. Let me know if I missed some technical details.

---

Reviewer Resources:

Track Policies

[IsaacG]

See https://exercism.org/docs/community/being-a-good-community-member/suggesting-exercise-improvements

These instruction files should not be modified directly.

If you would like to purpose a change to the wording, please open a thread on the forum. Thank you.

[rsp]

Thanks for the info @IsaacG. In the document that you referenced there is no info that such changes should be suggested on the forum, and after reading: "We're also nearly always open to changes in wording that add clarity, especially in Learning Exercises." I thought that a PR would be the best way to do it. Thanks for the clarification.

[IsaacG]

Two Fer is a practice exercise, so the text is shared across all tracks. It's not a learning exercise. Changes impacting 70+ tracks/maintainers bears discussing before changing. Not all tracks accept unsolicited PRs.

[glennj]

@IsaacG this PR relates to the instructions.append.md file, so it's bash-specific.

[glennj]

You wrote

and it is not the same as not passing the argument at all:

Perhaps

which is different from passing no arguments at all:

[rsp]

Sounds better, thanks. Changed in 079cb20

[glennj]

I don't think it's necessary to spell out the exact greeting or the exact error. Students are expected to read the tests to determine the complete requirements.

[rsp]

Very good point 👍 I removed the exact greeting and error in 079cb20

[glennj]

LGTM. @IsaacG can you have a look?

[IsaacG]

Minor language nits added. Though I'm not sure that this needs to be spelled out; the tests should enforce this.

[glennj]

Though I'm not sure that this needs to be spelled out; the tests should enforce this.

True, but it is one of the earliest exercises in the track. It's OK (IMO) to be over-specify the requirements a bit. I do have a TDD document to write...

[glennj]

@rsp if you'll make these suggested changes, we'll be ready to merge.

[rsp]

@glennj Thanks a lot, sounds much better now 👍 I committed all your suggestions.