Lectures

We break down why, in a CLI, you cannot make decisions based on the text of error, and we lock in the final error contract via the AppError type with fields Kind, Op, Err. We set up an unwrap chain via Unwrap(), extract the category via errors.As, introduce constructors ( Validation, IO, Internal), and show how this naturally yields predictable messages, logs, and exit codes.

We break down why in a CLI you cannot just print err, what the difference is between %w and %v in fmt.Errorf, how to do wrapping so that errors.Is/ errors.As work, where to add context (the Op field), and how to separate a user message from diagnostics. At the end: hands-on practice on the training CLI tasker and common mistakes.

We break down why exit code is a CLI contract for scripts and CI, how to keep a stable baseline scheme 0/ 1/ 2, how to classify errors via Kind and AppError (with errors.As/ errors.Is support), where to compute the exit code correctly (at the application boundary), and how to add “detailed” codes as a separate mode without breaking the baseline contract.

We break down how to collect several independent validation errors in Go into one via errors.Join, keep a stable item order, “unwrap” causes via the Unwrap() []error interface, and print a user-friendly CLI format: a short summary + a checklist of issues. We also show integration with AppError/ KindValidation, an output scenarios table, and common UX mistakes.

We break down a practical release ritual for a Go project: why the order matters, how to mitigate risks with the steps gofmt/ goimports → go test ./... → go vet ./... → linters ( staticcheck, golangci-lint) → build → short smoke scenarios. Using a CLI utility as an example, we lock in expectations for stdout/ stderr, exit codes, and add a doctor command for a quick “verification run.”