Your team owns a Go library other teams import. How do you decide where panics are allowed in it?

### What the policy actually decides "May this package panic?" looks like a coding-style question and is not. For a package other teams import, a panic on an exported path is a **behavioural contract that the type signature does not show**. Your importers cannot see it when they read `func (r *Rule) Apply(...) (bool, error)`, they inherit it in their own process, and in a server it typically becomes a restart rather than a failed request. That makes the decision an API-ownership call: the author proposes, the API reviewer or the consuming team can overrule, and once the package is out in the world the decision is expensive to reverse. ### The default rule to write down Start from a rule strict enough that it can be applied in review without argument: > No exported function in this package panics on a value the caller controls. Then enumerate the exceptions — a short, closed list, not a principle: 1. **Package-level `var` and `func init` on literals.** `regexp.MustCompile` on a pattern written in the source file, an embedded template that must parse. The failure is a build bug and it surfaces at process start, in tests and CI, before anything serves. 2. **A documented programmer-error contract**, such as using a type without the constructor the package requires. It must be in the doc comment on the exported name, or it does not count. 3. **Internal invariants**, in unexported code, whose message names the bug. Everything else — configuration, request data, file contents, environment — returns an error. ### Who owns the exceptions The useful organisational move is to make the exception list owned by the reviewer rather than the author. An author adding a `Must` call inside a function argues for it in the pull request; the reviewer's job is one question: *where did this argument come from?* That single question catches the most common regression in this area, which is not someone writing a reckless new panic but someone **moving** an existing, correct `MustCompile` out of a package-level variable and into a function so it can take a parameter. The diff looks like a refactor; the crash moved from startup into the request path. ### Enforcement that does not rely on vigilance Review alone decays. Back it with mechanism: - Adversarial tests over every exported function — zero values, nil maps, nil slices, wrong dynamic types — so a new panic fails a test rather than a deployment. - Fuzz targets for anything that parses caller bytes or strings. - A convention that `Must`-style helpers live only in `_test.go` files and in package-level declarations, which is a grep-able rule. - Package documentation that states the policy, so importers can rely on it and file a bug when it is broken. ### The tradeoffs to say out loud Being strict is not free, and a principal answer should price it: - **Plumbing.** Every rejected panic becomes an error return threaded through call sites that had nothing to say about it. Sometimes the right response is to restructure so validation happens once at the boundary rather than to thread an error through six layers. - **Convenience lost.** `Must` genuinely makes tests and static declarations pleasant. Keeping it legal in exactly those places preserves most of the benefit. - **The blanket-recover temptation.** Somebody will propose wrapping every exported entry point in a deferred recovery so "the library can never crash the caller". Refuse it for a library: it converts a bug into a wrong answer, hides the defect from the importer, and takes a decision that belongs to the process owner. Whether to install a last-resort recovery is the *application's* call, not the library's. - **Migration cost.** Removing a panic from a released exported function is a behaviour change for every importer. Where the fix needs a new signature, the pragmatic path is a new error-returning function alongside the old one, documented as the replacement, rather than a silent change of behaviour under the same name. ### Calibrating strictness to distance A final principle that makes the policy explainable: **the further your code is from the process that owns the crash, the less right it has to panic.** A `main` package may stop; a widely imported library may not. An internal tool with three known callers can be looser than a module a dozen teams depend on. State the rule per package, in its doc comment, and let the blast radius set the strictness rather than personal taste.