Panic dan Recover di Go: Runtime Panic dan Kapan Memakai Panic

Seperti apa panic itu

Panic menghentikan fungsi saat ini, menjalankan pemanggilan yang di-defer di fungsi itu, lalu melakukan hal yang sama di pemanggilnya, dan seterusnya naik ke atas stack. Kalau panic mencapai puncak goroutine, program akan crash.

package main

import "fmt"

func main() {
	defer fmt.Println("deferred in main: still runs")

	nums := []int{1, 2, 3}
	i := 5
	fmt.Println("before")
	fmt.Println(nums[i]) // panics
	fmt.Println("never printed")
}

Program ini keluar dengan status 2. Output-nya:

before
deferred in main: still runs
panic: runtime error: index out of range [5] with length 3

goroutine 1 [running]:
main.main()
	/tmp/main.go:11 +0x...
exit status 2

Pemanggilan yang di-defer berjalan sebelum laporan crash. Trace-nya menyebutkan goroutine, fungsi, dan barisnya, yang biasanya sudah cukup untuk menemukan bug-nya.

Runtime panic yang umum

Masing-masing adalah bug di program, bukan kondisi yang perlu ditangani. Perbaikannya adalah pemeriksaan batas, pemeriksaan nil, make, atau assertion comma-ok, bukan recover.

Melakukan recover

recover() menghentikan panic. Fungsi ini hanya bekerja kalau dipanggil langsung di dalam fungsi yang di-defer, karena fungsi yang di-defer adalah satu-satunya kode yang berjalan saat panic membongkar stack.

package main

import "fmt"

func safeDivide(a, b int) (result int, err error) {
	defer func() {
		if r := recover(); r != nil {
			err = fmt.Errorf("recovered: %v", r)
		}
	}()
	return a / b, nil
}

func main() {
	fmt.Println(safeDivide(10, 2))
	fmt.Println(safeDivide(1, 0))
	fmt.Println("program continues")
}

Output:

5 <nil>
0 recovered: runtime error: integer divide by zero
program continues

Yang terjadi di pemanggilan kedua:

1. a / b memicu panic.
2. Closure yang di-defer berjalan, dan recover() mengembalikan nilai panic-nya (sebuah runtime.Error).
3. Pembongkaran stack berhenti. safeDivide kembali normal ke main, dengan named result err yang diisi oleh closure.

Named result itulah yang memungkinkan fungsi yang di-defer mengembalikan error. Tanpa named result, fungsi akan mengembalikan zero value-nya. Halaman defer membahas cara closure yang di-defer mengubah hasil.

recover() mengembalikan nil saat tidak ada panic, jadi pemeriksaan if r != nil membuat fungsi yang di-defer tidak berbahaya di jalur normal. Kalau dipanggil di luar fungsi yang di-defer, atau di fungsi yang dipanggil oleh fungsi yang di-defer, recover mengembalikan nil dan tidak melakukan apa pun.

panic dengan nilaimu sendiri

panic menerima nilai apa pun. Biasanya berupa error atau string.

package main

import (
	"errors"
	"fmt"
)

var ErrInvariant = errors.New("invariant violated")

func mustPositive(n int) int {
	if n <= 0 {
		panic(fmt.Errorf("mustPositive(%d): %w", n, ErrInvariant))
	}
	return n
}

func main() {
	defer func() {
		r := recover()
		if err, ok := r.(error); ok && errors.Is(err, ErrInvariant) {
			fmt.Println("caught:", err)
			return
		}
		if r != nil {
			panic(r) // not ours: re-panic
		}
	}()

	fmt.Println(mustPositive(3))
	fmt.Println(mustPositive(-1))
}

Lakukan recover untuk apa yang kamu harapkan, dan panic ulang untuk yang lainnya. Menelan setiap panic akan menyembunyikan bug yang sebenarnya.

Sejak Go 1.21, panic(nil) diubah menjadi *runtime.PanicNilError, jadi recover() yang mengembalikan nil kini selalu berarti "tidak ada panic".

Panic di goroutine

recover hanya menangkap panic di goroutine-nya sendiri. Panic di goroutine mana pun tanpa recover akan mematikan seluruh proses, termasuk main dan setiap goroutine lainnya.

package main

import (
	"fmt"
	"sync"
)

func safeGo(wg *sync.WaitGroup, name string, f func()) {
	wg.Add(1)
	go func() {
		defer wg.Done()
		defer func() {
			if r := recover(); r != nil {
				fmt.Printf("worker %s panicked: %v\n", name, r)
			}
		}()
		f()
	}()
}

func main() {
	var wg sync.WaitGroup
	safeGo(&wg, "ok", func() { fmt.Println("worker ok done") })
	safeGo(&wg, "bad", func() {
		var m map[string]int
		m["x"] = 1
	})
	wg.Wait()
	fmt.Println("main finished")
}

Kedua baris worker bisa tercetak dalam urutan mana pun; main finished selalu muncul terakhir. defer recover() di main tidak akan menyelamatkan program dari worker kedua. Inilah sebabnya HTTP server melakukan recover per request: net/http melakukan recover terhadap panic di setiap goroutine handler, mencatatnya di log, lalu menutup koneksi itu, sehingga satu request yang buruk tidak menjatuhkan server.

Beberapa kegagalan adalah fatal error, bukan panic, dan sama sekali tidak bisa di-recover: concurrent map writes, kehabisan memori, dan all goroutines are asleep dari pendeteksi deadlock.

Kapan panic adalah pilihan yang tepat

Aturan umum Go: kembalikan error untuk apa pun yang bisa salah saat program berjalan, dan pakai panic hanya untuk kesalahan programmer. Secara konkret, panic tepat dipakai saat:

• Sebuah invariant rusak. switch pada enum buatanmu sampai ke kasus yang tidak mungkin terjadi. Melanjutkan program justru akan merusak data.
• Helper Must menerima input konstanta yang salah. regexp.MustCompile, template.Must, dan uuid.MustParse membungkus fungsi yang mengembalikan error lalu memicu panic saat gagal. Pakai untuk nilai yang sudah diketahui saat kompilasi, biasanya variabel level package, di mana kegagalan berarti source code-nya yang salah:

var emailRE = regexp.MustCompile(`^[^@\s]+@[^@\s]+$`)

• Startup tidak bisa dilanjutkan. Konfigurasi wajib tidak ada di main. Bahkan di sini, mencetak error lalu memanggil os.Exit(1) sering lebih rapi daripada stack trace.

Panic adalah alat yang salah untuk:

• Kegagalan yang bisa diperkirakan: input pengguna yang tidak valid, file yang tidak ada, timeout. Kembalikan error; lihat penanganan error.
• Alur kontrol: memakai panic dan recover seperti exception di sepanjang call tree yang besar membuat kode sulit diikuti. Standard library melakukannya secara internal di beberapa tempat (encoder encoding/json), selalu dengan recover sebelum kembali, sehingga tidak ada panic yang lolos dari package-nya.
• API library: library yang memicu panic saat menerima input yang salah memaksa setiap pemanggil menambahkan recover. Kembalikan error.

Kesalahan umum

• Memanggil recover di luar fungsi yang di-defer. Hasilnya nil.
• Melakukan recover di main untuk panic dari goroutine. Setiap goroutine butuh recover-nya sendiri.
• Menelan semua panic. Catat di log beserta stack-nya (debug.Stack() dari runtime/debug) dan panic ulang untuk yang tidak kamu harapkan.
• Memakai recover untuk menangani penulisan ke map nil atau indeks di luar batas. Perbaiki bug-nya saja.