Why should log.Fatal never appear in a Go library or a helper function?

## What log.Fatal actually is The standard `log` package's `Fatal`, `Fatalf` and `Fatalln` are documented as equivalent to the matching `Print` call **followed by `os.Exit(1)`**. There is no magic: a message goes to the logger's output (standard error by default, with a date and time prefix), and then the process terminates with status 1. The important half is `os.Exit`. It ends the program right there - **deferred functions do not run**, in the calling goroutine or anywhere else, and other goroutines are not given a chance to finish. Anything a program was relying on `defer` to do simply does not happen. ## What that costs when a helper calls it Consider a scheduled job whose helper parses configuration out of environment variables at startup: ```go func mustEnvInt(name string) int { v, err := strconv.Atoi(os.Getenv(name)) if err != nil { log.Fatalf("%s: %v", name, err) } return v } ``` If that helper is called after the job has already created a lock file and registered `defer os.Remove(lockPath)`, the lock file survives the exit. The next scheduled run finds a lock nobody holds and refuses to start, and the incident is now two incidents. The same story covers a half-written output file that a deferred rename would have made atomic, a temporary directory a deferred cleanup would have removed, and an in-flight batch a deferred flush would have committed. The deeper problem is authority. A library or helper cannot know what the failure means to its caller. A missing environment variable is fatal to a one-shot job, a reason to fall back to a default in a long-running server, and just an expected condition in a test that is checking the error path. By calling `log.Fatal` the helper takes that decision away from every caller it will ever have. ## What it does to tests A test that exercises the failing path does not fail - it **terminates the test binary**. No remaining tests run, no per-test output is printed, and the reported result is an exit status rather than an assertion message. Testing a fatal path at all requires re-executing the test binary as a subprocess, which is a lot of machinery to work around a line that should have returned an error. ## The fix Return the error and wrap it with what this layer knows: ```go func envInt(name string) (int, error) { v, err := strconv.Atoi(os.Getenv(name)) if err != nil { return 0, fmt.Errorf("env %s: %w", name, err) } return v, nil } ``` Now a server can substitute a default, a job can abort cleanly with its defers running, and a test can assert on the returned error in a single line. ## Where a fatal call is still acceptable `main` is the one function that legitimately owns the decision to stop the process, because there is nobody above it. Even there, the common shape is to keep the exit at a single point so that everything else can use `defer` normally: `main` calls a `run() error`, and only after `run` has returned - with all of its deferred cleanup finished - does `main` report the error once and exit non-zero. A related, narrower exception is a `Must`-style helper used in package-level variable initialisation of a program that genuinely cannot start without the value - `template.Must` and `regexp.MustCompile` follow this pattern, but note that those **panic** rather than exit. A panic still runs deferred functions as the stack unwinds and can be recovered by a caller that wants to; `os.Exit` offers neither. ## How to spot it Grep the repository for `log.Fatal` and `os.Exit` and check the package of every hit. Anything outside the main package - and outside `main` itself - deserves a question in review. A convention that says "only `main` may end the process" is easy to state, easy to check, and removes an entire class of half-finished-cleanup incidents.