More About Deferred Function Calls

Deferred function calls have been introduced before. Due to the limited knowledge at that time, some more details and use cases of deferred functions calls are not touched in that article. These details and use cases will be touched in the remaining of this article.

Calls To Many Built-in Functions With Return Results Can't Be Deferred

In Go, the result values of a call to custom functions can be all absent (discarded). However, for built-in functions with non-blank return result lists, the result values of their calls mustn't be absent (up to Go 1.10), except the calls to the built-in copy and recover functions. We have learned that the result values of a deferred function call must be discarded, so the calls to many built-in functions can't be deferred.

Fortunately, the needs to defer built-in function calls (with non-blank return result lists) are rare. As far as I know, only the calls to the built-in append function may be needed to defer sometimes. For this case, we can defer a call to an anonymous function which wrapps the append call.
package main

import "fmt"

func main() {
	s := []string{"a", "b", "c", "d"}
	defer fmt.Println(s) // [a x y d]
	// defer append(s[:1], "x", "y") // error
	defer func() {
		_ = append(s[:1], "x", "y")
	}()
}

The Evaluation Moment Of Deferred Function Values

The called function in a deferred function call may be a nil function value. For such a case, the panic will occur before the deferred call is pushed into the deferred call stack of the currrent goroutine. An example:
package main

import "fmt"

func main() {
	defer fmt.Println("reachable")
	var f func() // f is nil by default
	defer f()    // panic here
	// The following lines are dead code.
	fmt.Println("not reachable")
	f = func() {}
}

The argumnts of a deferred function call are also evaluated before the deferred call is pushed into the deferred call stack of the currrent goroutine.

Deferred Calls Make Code Cleaner And Less Bug Prone

Example:
import "os"

func withoutDefers(filepath string, head, body []byte) error {
	f, err := os.Open(filepath)
	if err != nil {
		return err
	}

	_, err = f.Seek(16, 0)
	if err != nil {
		f.Close()
		return err
	}

	_, err = f.Write(head)
	if err != nil {
		f.Close()
		return err
	}

	_, err = f.Write(body)
	if err != nil {
		f.Close()
		return err
	}

	err = f.Sync()
	f.Close()
	return err
}

func withDefers(filepath string, head, body []byte) error {
	f, err := os.Open(filepath)
	if err != nil {
		return err
	}
	defer f.Close()

	_, err = f.Seek(16, 0)
	if err != nil {
		return err
	}

	_, err = f.Write(head)
	if err != nil {
		return err
	}

	_, err = f.Write(body)
	if err != nil {
		return err
	}

	return f.Sync()
}

Which one looks cleaner? apparently, the one with the deferrd calls, though a little. And it is less bug prone, what about if any if f.Close() calls in the other one is missed? ;)

Performance Losses Caused By Deferring Function Calls

It is not always good to use defered function calls. Up to now (Go 1.10), for the offical Go compiler, deferred function calls will cause some performance losses at run time, in particular for deferred function calls within loop code blocks.

For example, in the following example, method IncreaseB is much more efficient than IncreaseA.
import "sync"

type T struct {
	mu sync.Mutex
	n  int64
}

func (t *T) IncreaseA() {
	t.mu.Lock()
	defer t.mu.Unlock()
	t.n++
}

func (t *T) IncreaseB() {
	t.mu.Lock()
	t.n++
	t.mu.Unlock()
}

A very large deferred call stack may also consume much memory. Sometimes, we can make some deferred function calls get executed earlier to avoid accumulating too many deferred calls. For example,
func writeManyFile(files []File) error {
	for _, file := range files {
		f, err := os.Open(file.path)
		if err != nil {
			return err
		}
		defer f.Close()

		_, err = f.WriteString(file.content)
		if err != nil {
			return err
		}

		err = f.Sync()
		if err != nil {
			return err
		}
	}

	return nil
}
can be rewrittn and optimized as
func writeManyFile(files []File) error {
	for _, file := range files {
		if err := func() error {
			f, err := os.Open(file.path)
			if err != nil {
				return err
			}
			defer f.Close()

			_, err = f.WriteString(file.content)
			if err != nil {
				return err
			}

			return f.Sync()
		}(); err != nil {
			return err
		}
	}

	return nil
}

Currently, if you really care about the performance of your programs, you can try to avoid using unnecessary deferred function calls.

Welcome to improve Go 101 articles by submitting corrections for all kinds of mistakes, such as typos, grammar errors, wording inaccuracies description flaws and code bugs.