Chapter 6 Functions, Defer, and Panic on Go: Under the Hood

6.1 Function Calls

Mon, 01 Jan 0001 00:00:00 +0000

6.1 Function Calls

Functions are first-class citizens in Go: they can be assigned, passed, returned, and they can capture outer variables to become closures. Behind this lie two implementation questions: how a function value (a closure) is represented in memory, and how a single function call passes arguments and returns values at the lowest level. The latter also hides a quiet but sweeping change introduced in Go 1.17: passing arguments in registers instead of on the stack. This section explains both thoroughly, and at the seam between them points out a key fact, the very fact that welds “what a closure is” and “how a call happens” into one and the same thing.

6.2 Deferred Statements

Mon, 01 Jan 0001 00:00:00 +0000

6.2 Deferred Statements

The deferred statement defer did not exist in the earliest Go designs; it was added later as a separate feature, with Robert Griesemer writing the language specification [Griesemer, 2009] and Ken Thompson producing the earliest implementation [Thompson, 2009]. Its semantics read very short: a defer-red call runs when the enclosing function returns, when a panic occurs, or when runtime.Goexit is called. Intuitively this looks like a purely compile-time feature, similar to C++’s RAII (automatic destruction when leaving a scope); the compiler would seem to only need to “move” the deferred call to the end of the function, with no runtime cost.

6.3 The panic and recover Builtins

Mon, 01 Jan 0001 00:00:00 +0000

6.3 The panic and recover Builtins

defer (6.2) has already settled the question of “what to do when a function exits,” leaving open the question of “what happens when a function is interrupted abnormally.” The pair of builtins panic and recover answers exactly this: the former interrupts the current normal control flow and begins unwinding up the call stack, while the latter catches it mid-unwind. This section first makes their semantics clear, then comes down to the go1.26 runtime implementation of gopanic and gorecover, and finally returns to a more pressing question: what panic should really be taken to be, and why Go did not make it into an exception mechanism like the one in C++ or Java.