Deferred function calls have been introduced before. Due to the limited Go 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.
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
(at least for Go 1.20),
except the calls to the built-in copy and recover functions.
On the other hand, 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.
append function
may needed to be deferred sometimes.
For this case, we can defer a call to an anonymous function
which wraps 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")
}()
}
false.
package main
import "fmt"
func main() {
var f = func () {
fmt.Println(false)
}
defer f()
f = func () {
fmt.Println(true)
}
}
package main
import "fmt"
func main() {
defer fmt.Println("reachable 1")
var f func() // f is nil by default
defer f() // panic here
// The following lines are also reachable.
fmt.Println("reachable 2")
f = func() {} // useless to avoid panicking
}
As explained before, the arguments of a deferred function call are also evaluated when the deferred call is pushed into the deferred call queue of the current goroutine.
Method receiver arguments are also not exceptions. For example, the following program prints1342.
package main
type T int
func (t T) M(n int) T {
print(n)
return t
}
func main() {
var t T
// "t.M(1)" is the receiver argument of the method
// call ".M(2)", so it is evaluated when the
// ".M(2)" call is pushed into deferred call queue.
defer t.M(1).M(2)
t.M(3).M(4)
}
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 deferred calls, though a little.
And it is less bug prone, for there are so many f.Close() calls in the
function without deferred calls that it has a higher possibility to miss one of them.
doSomething calls panic in the following example,
the function f2 will exit without unlocking the Mutex value.
So the function f1 is less bug prone.
var m sync.Mutex
func f1() {
m.Lock()
defer m.Unlock()
doSomething()
}
func f2() {
m.Lock()
doSomething()
m.Unlock()
}
It is not always good to use deferred function calls. For the official Go compiler, before version 1.13, deferred function calls will cause a few performance losses at run time. Since Go Toolchain 1.13, some common defer use cases have got optimized much, so that generally we don't need to care about the performance loss problem caused by deferred calls. Thank Dan Scales for making the great optimizations.
func writeManyFiles(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
}
func writeManyFiles(files []File) error {
for _, file := range files {
if err := func() error {
f, err := os.Open(file.path)
if err != nil {
return err
}
// The close method will be called at
// the end of the current loop step.
defer f.Close()
_, err = f.WriteString(file.content)
if err != nil {
return err
}
return f.Sync()
}(); err != nil {
return err
}
}
return nil
}
The Go 101 프로젝트는 Github 에서 호스팅됩니다. 오타, 문법 오류, 부정확한 표현, 설명 결함, 코드 버그, 끊어진 링크와 같은 모든 종류의 실수에 대한 수정 사항을 제출하여 Go 101을 개선을 돕는 것은 언제나 환영합니다.
주기적으로 Go에 대한 깊이 있는 정보를 얻고 싶다면 Go 101의 공식 트위터 계정인 @go100and1을 팔로우하거나 Go 101 슬랙 채널에j가입해주세요.
reflect 표준 패키지sync 표준 패키지sync/atomic 표준 패키지