How does runtime.Goexit differ from returning from a goroutine's function, and from os.Exit?

## Three different "stops" Go gives you three quite distinct ways to stop doing something, and they operate at different scopes: | construct | scope | deferred calls | recoverable | |---|---|---|---| | `return` | the current function | that function's defers run | n/a | | `runtime.Goexit()` | the calling goroutine | *all* pending defers in that goroutine run | no — `recover` sees `nil` | | `os.Exit(code)` | the whole process | none run, anywhere | no | A panic is a fourth: it unwinds the calling goroutine running defers, *can* be stopped by `recover`, and kills the process if it reaches the top of the stack unrecovered. ## What `runtime.Goexit` does, precisely `Goexit` takes no arguments and never returns. It terminates the goroutine that calls it, and no other goroutine is affected. Before the goroutine ends, the runtime walks its stack and runs every deferred call that is still pending — not just the ones in the function that called `Goexit`, but the ones in every frame below it too. That makes it a *clean* exit for one goroutine: files close, mutexes registered with `defer mu.Unlock()` unlock, cleanup runs. The part people get wrong is the interaction with `recover`. Because `Goexit` is not a panic, a deferred function that calls `recover` gets `nil` back. There is no way to catch it and resume normal execution; the deferred calls run, and then the goroutine is finished regardless of what they do. ```go done := make(chan bool) go func() { defer func() { fmt.Println("deferred ran; recover() ==", recover()) done <- true }() runtime.Goexit() fmt.Println("never reached") }() <-done ``` ## Why the language needs it at all A plain `return` only ends the function you are standing in. If you are five frames deep inside a helper and you have decided this goroutine has nothing more to do, `return` obliges every caller in between to check a value and return too. `Goexit` gives you an escape hatch that still respects cleanup. The standard library uses exactly that. `testing.T.FailNow` marks the test failed and then calls `runtime.Goexit`, and `t.Fatal`/`t.Fatalf` are `Log` followed by `FailNow`. That is why `t.Fatal` inside a deeply nested test helper stops the test rather than merely recording a failure, and why the test's deferred cleanups and functions registered with `t.Cleanup` still run. It is also why the documentation insists `FailNow` be called from the goroutine running the test: calling it from a goroutine the test spawned kills only that goroutine, and the test carries on, unaware. ## `Goexit` on the main goroutine This is the case worth memorising. `Goexit` terminates the main goroutine *without `main` returning*. Since `main` never returned, the runtime does not tear the program down; it keeps running whatever other goroutines exist. If those goroutines finish or block forever, there is eventually nothing left to schedule, and the runtime kills the program with a fatal error reporting a deadlock and naming `Goexit` as the reason `main` is gone. The program dies, but as a crash — not as a clean exit with a status you chose. So `Goexit` is emphatically not "exit the program cleanly from anywhere". If you want the process to end with a status, that is `os.Exit`, or returning from `main`. ## How this contrasts with `os.Exit` `os.Exit` is the whole-program hammer: the process ends at that statement with the status you pass, no defers run in any goroutine, and nothing buffered in program memory is flushed. `Goexit` is the opposite in every respect — narrow scope, defers honoured, process untouched, no status involved. The two also fail in opposite ways. Misusing `os.Exit` loses cleanup you expected to happen; misusing `Goexit` leaves a program alive that you expected to have ended, or silently drops a goroutine you thought was still working. ## Practical guidance Most application code never calls `Goexit` directly — returning from the goroutine's top-level function is clearer and does the same thing for that goroutine. Reach for `Goexit` when you are building something test-harness-shaped, where a helper several frames down must be able to abandon the current unit of work while cleanup still runs. Recognise it in a stack trace or a goroutine dump, and never assume a deferred `recover` will hold it back.