What rule would you set for os.Exit and log.Fatal in shared Go packages, and how would you enforce it?

## The decision being made Calling `os.Exit` is not an error-handling choice; it is a statement about the whole program. It says: whatever else this process was doing, whatever cleanup was pending, whatever output was buffered, none of it matters. That is a legitimate decision — but only the owner of the process can make it, because only they know what else is running. A shared package does not know. It might be linked into a CLI where exiting is fine, a long-running service where exiting is an outage, a test binary where exiting destroys the run, or another team's batch job where exiting truncates a report. Which is why the rule is about *where* the call may live rather than *whether* exiting is ever right. ## The rule **`os.Exit` and `log.Fatal`/`Fatalf`/`Fatalln` may appear only in `package main`.** Everything else returns an error. Inside `main`, aim for a single exit site, positioned after buffered writers have been flushed and their errors checked, so the exit is the last thing that happens and not a shortcut taken halfway through. Two corollaries worth writing down explicitly, because they are the ones people get wrong: - `log.Fatal` is an exit call. Teams that ban `os.Exit` in libraries and leave `log.Fatal` alone have banned nothing; the Fatal family prints and then calls `os.Exit(1)`. - A `defer` does not save you inside `main` either. `defer w.Flush()` in `main` does not run if `main` itself ends with `os.Exit`. The flush must precede the exit on every path. ## What the rule buys - **Testability.** A package that exits cannot be tested for that path at all: the test binary dies, usually without telling you which test was running. The equivalent in tests is `t.Fatal`, which ends only the test's goroutine (via `runtime.Goexit`) and lets cleanup run — exactly the scoped behaviour library code should be aiming for. - **Reusability.** The utility written for a cron job gets imported by a service six months later. If it exits on bad input, the service now has a crash path it cannot intercept. - **Diagnosability.** An error that travels up the stack can be wrapped with context at each layer. An exit produces one line and a status code. - **Data safety.** Every caller's deferred flush, close and unlock is skipped. In a tool whose output *is* the deliverable, that is the difference between a usable report and a truncated one. ## What it costs, and where I would bend The cost is real and worth naming rather than waving away. `log.Fatalf("bad config: %v", err)` is one line; threading an error up through four callers is a signature change at each of them. In a fifty-line internal tool with one author, insisting on the ceremony is a poor trade, and I would accept exits in a `main` package's own helpers there. Where I would not bend: anything with an import path other teams use, anything that might end up inside a server, and anything whose output must be complete to be worth anything. Those are the boundaries you cannot renegotiate cheaply once people depend on them. There is also a genuine counter-argument to hear out: for a condition where continuing would corrupt data, exiting immediately can be safer than returning an error a caller might swallow. My answer is usually `panic` rather than `os.Exit` — it runs the defers, prints a stack that names the cause, and still leaves a caller the option to recover at a boundary — but if someone owns a tool where an immediate hard stop really is the safer failure mode, that is a decision to document and scope, not to spread. ## Enforcement A rule without a check is a preference. In order of what actually holds: 1. **A CI check** that fails when `os.Exit` or the `log` Fatal family appears outside `package main`, with a small, reviewed allowlist. It runs on every change, so new violations cannot arrive quietly. 2. **An allowlist that is visible and short.** Each entry names who accepted the exception and why. Growth in that file is the signal that the rule needs revisiting. 3. **Making the right path the easy one.** If every tool in the repo has the same shape — helpers return errors, `main` flushes and exits — the correct code is the code people copy. 4. **Review as the last line, not the first.** Reviewers miss a `log.Fatal` in a diff of two hundred lines; the check does not. Migrating an existing codebase, I would gate new packages immediately, fix existing violations on the paths that produce output first (those are the ones losing data), and let the rest come with normal churn rather than opening a large mechanical change nobody can review. ## What an interviewer listens for That you treat exiting as an ownership question rather than a style question, that you can price the inconvenience honestly instead of declaring the rule obviously correct, that you know `log.Fatal` is the same call, and that you propose something checkable rather than a paragraph in a wiki.