Defer di Golang: Urutan, Evaluasi Argumen, dan Jebakannya

Apa yang dilakukan defer

defer memasukkan sebuah pemanggilan fungsi ke dalam daftar. Saat fungsi di sekitarnya selesai, daftar itu dijalankan dengan urutan terbalik.

package main

import "fmt"

func main() {
	fmt.Println("start")
	defer fmt.Println("deferred 1")
	defer fmt.Println("deferred 2")
	defer fmt.Println("deferred 3")
	fmt.Println("end")
}

Output:

start
end
deferred 3
deferred 2
deferred 1

Urutannya adalah terakhir masuk, pertama keluar, seperti stack. Itu sesuai dengan cara resource bersarang: kalau kamu membuka A lalu B, biasanya kamu ingin menutup B sebelum A.

Pembersihan di sebelah pengambilan resource

Kegunaan utama defer adalah menulis kode pembersihan tepat di baris setelah resource diambil, sehingga tidak ada jalur return yang bisa melupakannya.

package main

import (
	"bufio"
	"fmt"
	"os"
)

func countLines(path string) (int, error) {
	f, err := os.Open(path)
	if err != nil {
		return 0, err
	}
	defer f.Close()

	n := 0
	sc := bufio.NewScanner(f)
	for sc.Scan() {
		n++
	}
	return n, sc.Err()
}

func main() {
	tmp, err := os.CreateTemp("", "defer-*.txt")
	if err != nil {
		fmt.Println(err)
		return
	}
	defer os.Remove(tmp.Name())
	fmt.Fprint(tmp, "one\ntwo\nthree\n")
	tmp.Close()

	n, err := countLines(tmp.Name())
	fmt.Println(n, err)

	_, err = countLines("/does/not/exist")
	fmt.Println(err)
}

Perhatikan urutannya: periksa error dulu, baru defer. Kalau os.Open gagal, f bernilai nil, dan men-defer f.Close() sebelum pemeriksaan akan memanggil Close pada *os.File yang nil (yang mengembalikan error yang tidak pernah kamu lihat, dan membingungkan pembaca kode).

Bentuk yang sama berlaku untuk lock:

mu.Lock()
defer mu.Unlock()

Kalau kode di antara keduanya panic, kunci mutex tetap dibuka.

Argumen langsung dievaluasi

Fungsi yang di-defer beserta argumennya dievaluasi saat pernyataan defer dijalankan. Hanya pemanggilannya yang menunggu.

package main

import "fmt"

func main() {
	x := 1
	defer fmt.Println("deferred with argument:", x)
	defer func() {
		fmt.Println("deferred closure reads:", x)
	}()
	x = 2
	fmt.Println("x is now", x)
}

Output:

x is now 2
deferred closure reads: 2
deferred with argument: 1

fmt.Println("...", x) menangkap nilai 1 di baris defer. Closure tidak punya argumen; ia membaca x saat akhirnya dijalankan. Pilih bentuk yang sesuai dengan apa yang ingin kamu catat.

Aturan ini juga berlaku untuk receiver method. defer t.Stop() langsung mengevaluasi t, jadi meng-assign ulang t setelahnya tidak mengubah nilai mana yang dihentikan.

Trik pengukuran waktu yang umum memakai aturan ini dengan sengaja:

func handle() {
	defer trace("handle")() // trace runs now, the returned func runs at exit
	// ...
}

trace("handle") langsung dipanggil (ia bisa mencetak "enter" dan mencatat waktu mulai), dan fungsi yang dikembalikannya itulah yang di-defer.

Defer di dalam loop

Pemanggilan defer berjalan saat fungsi selesai, bukan di akhir setiap iterasi loop. Di dalam loop yang memproses banyak file, ini membuat setiap file tetap terbuka sampai fungsinya selesai.

for _, path := range paths {
	f, err := os.Open(path)
	if err != nil {
		return err
	}
	defer f.Close() // all files stay open until the function returns
	process(f)
}

Dengan ribuan path, ini akan kehabisan file descriptor. Pindahkan badan loop ke fungsinya sendiri supaya setiap defer berjalan per iterasi:

package main

import (
	"fmt"
	"os"
)

func processFile(path string) error {
	f, err := os.Open(path)
	if err != nil {
		return err
	}
	defer f.Close()
	info, err := f.Stat()
	if err != nil {
		return err
	}
	fmt.Println(info.Name(), info.Size(), "bytes")
	return nil
}

func main() {
	dir, err := os.MkdirTemp("", "defer-loop")
	if err != nil {
		fmt.Println(err)
		return
	}
	defer os.RemoveAll(dir)

	var paths []string
	for i := range 3 {
		p := fmt.Sprintf("%s/file%d.txt", dir, i)
		if err := os.WriteFile(p, make([]byte, i*10), 0o644); err != nil {
			fmt.Println(err)
			return
		}
		paths = append(paths, p)
	}
	for _, p := range paths {
		if err := processFile(p); err != nil {
			fmt.Println(err)
		}
	}
}

Setiap pemanggilan processFile menutup file-nya sebelum file berikutnya dibuka. Function literal yang langsung dipanggil di tempat (func() { ... }()) bekerja dengan cara yang sama saat fungsi helper bernama terasa berlebihan.

Mengubah nilai kembalian

Closure yang di-defer berjalan setelah pernyataan return mengisi hasilnya, dan closure itu bisa mengubah hasil bernama sebelum pemanggil melihatnya.

package main

import (
	"errors"
	"fmt"
)

func double(n int) (result int) {
	defer func() { result *= 2 }()
	return n // result = n, then the defer doubles it
}

func save() (err error) {
	defer func() {
		if err != nil {
			err = fmt.Errorf("save failed: %w", err)
		}
	}()
	return errors.New("disk full")
}

func main() {
	fmt.Println(double(5))
	fmt.Println(save())
}

Program ini mencetak 10 dan save failed: disk full. Dengan hasil yang tidak bernama, fungsi yang di-defer tetap bisa berjalan, tetapi tidak punya cara untuk mengubah apa yang dikembalikan.

Menangkap error dari Close

defer f.Close() membuang error dari Close. Untuk file yang hanya kamu baca, itu tidak masalah. Untuk file yang kamu tulis, Close bisa melaporkan flush terakhir yang gagal, jadi error-nya penting. Hasil bernama memungkinkanmu menyimpannya:

func writeReport(path string, data []byte) (err error) {
	f, err := os.Create(path)
	if err != nil {
		return err
	}
	defer func() {
		if cerr := f.Close(); cerr != nil && err == nil {
			err = cerr
		}
	}()
	_, err = f.Write(data)
	return err
}

errors.Join(err, f.Close()) adalah alternatif yang lebih singkat saat kamu ingin kedua error dilaporkan.

Defer, panic, dan recover

Pemanggilan defer berjalan selama panic membongkar stack. Hanya di sanalah recover berpengaruh, dan begitulah cara sebuah server mencegah satu request yang bermasalah mematikan seluruh proses. Detailnya ada di panic dan recover.

Pemanggilan defer tidak berjalan saat program keluar lewat os.Exit atau log.Fatal. Kalau main men-defer pembersihan lalu memanggil os.Exit(1), pembersihan itu dilewati.

Biaya

Sejak Go 1.14, kebanyakan defer di-open-code oleh compiler dan hanya memakan beberapa nanodetik. Memakai defer untuk setiap pelepasan mutex dan penutupan file adalah gaya yang normal. Defer di dalam loop adalah pengecualian: defer seperti itu tidak bisa di-open-code dan memakai jalur yang lebih lambat, satu alasan lagi untuk memindahkan badan loop ke dalam fungsi.

Kesalahan umum

• Men-defer sebelum memeriksa error. Periksa err dari Open dulu, lalu defer Close.
• Mengharapkan pembersihan per iterasi di dalam loop. Defer berjalan saat fungsi selesai.
• Mengharapkan argumen yang di-defer melihat perubahan sesudahnya. Argumen sudah tetap di baris defer. Pakai closure untuk membaca nilainya saat fungsi selesai.
• Mengandalkan defer bersama os.Exit. Defer tidak pernah berjalan.