Lesson 3: Go setup and toolchain: Debugging scenario

Concept Explanation

Debugging in Go often starts with small, explicit checks instead of hidden magic. In this lesson, you will work with the common Go pattern of returning an error, checking it immediately, and wrapping it with better context. The aim is to build the habit of reading failures carefully, improving the message, and keeping the control flow obvious for the next person who reads the code.

Where to Put the Code

1. Define color and position variables at the top.
2. Create shape drawing or placement logic in the middle.
3. Render output (print, canvas, SVG, or styled block) at the end.

Command Reference

• Check errors right after the operation that can fail so the source of the problem stays obvious.
• Use `fmt.Printf` with `%q` or `%v` when you want clearer debugging output in the terminal.
• Improve an error message by adding context about the input or step that failed.
• Rerun the program with both failing and valid input so you can compare behavior directly.

Step-by-step Guide

1. Run the starter program with the broken input and read the error message carefully.
2. Replace the bad value with a valid numeric string and confirm the success path works.
3. Restore the invalid input, but rewrite the message so it gives better context to the reader.
4. Explain why the program returns immediately after handling the error.
5. Finish by listing one thing that made the debugging process easier.

Practice Exercises

• Change the example to test two different invalid values and compare the messages.
• Create a version that reads a string variable named `ageText` and converts it to an integer.
• Rewrite the output so success and failure messages are visually distinct and easy to scan.

Coding Challenges

• Wrap the conversion in a helper function that returns `(int, error)` and keep the error message clear.
• Design a tiny debugging example where the failure comes from empty input instead of invalid characters.

Mini Practice Tasks

• Test one valid and one invalid input.
• Improve the wording of the error message.
• Write a one-line summary of why Go checks `err` explicitly.