Panic và recover trong Go: lỗi runtime và khi nào nên panic

Panic trông như thế nào

Panic dừng hàm hiện tại, chạy các lời gọi đã defer của nó, rồi làm tương tự ở hàm gọi nó, cứ thế đi ngược lên ngăn xếp. Nếu lên tới đỉnh của goroutine, chương trình sẽ sập.

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")
}

Chương trình này thoát với mã trạng thái 2. Đầu ra là:

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

Lời gọi đã defer chạy trước báo cáo sự cố. Stack trace ghi tên goroutine, hàm và dòng code, thường là đủ để tìm ra bug.

Các panic runtime thường gặp

Mỗi lỗi ở trên là một bug trong chương trình, không phải một tình huống cần xử lý. Cách sửa là kiểm tra giới hạn, kiểm tra nil, gọi make, hoặc dùng assertion dạng comma-ok, chứ không phải recover.

Recover

recover() dừng một panic. Nó chỉ hoạt động khi được gọi trực tiếp bên trong một hàm được defer, vì hàm được defer là code duy nhất chạy trong lúc panic tháo ngăn xếp.

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")
}

Đầu ra:

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

Chuyện gì đã xảy ra ở lần gọi thứ hai:

1. a / b gây panic.
2. Closure được defer chạy, và recover() trả về giá trị panic (một runtime.Error).
3. Việc tháo ngăn xếp dừng lại. safeDivide trả về bình thường cho main, với named result err được closure gán giá trị.

Chính named result cho phép hàm được defer trả lỗi về. Nếu không có nó, hàm trả về các giá trị zero. Trang defer trình bày cách closure được defer thay đổi kết quả.

recover() trả về nil khi không có panic, nên phép kiểm tra if r != nil giúp hàm được defer vô hại ở luồng bình thường. Gọi bên ngoài hàm được defer, hoặc trong một hàm được hàm defer gọi tới, recover trả về nil và không làm gì.

panic với giá trị của riêng bạn

panic nhận bất kỳ giá trị nào. Thường là một error hoặc một chuỗi.

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))
}

Hãy recover những gì bạn lường trước và panic lại với mọi thứ khác. Nuốt hết mọi panic sẽ che giấu các bug thật.

Từ Go 1.21, panic(nil) được chuyển thành *runtime.PanicNilError, nên giờ recover() trả về nil chắc chắn có nghĩa là "không có panic".

Panic trong goroutine

recover chỉ bắt được panic trong goroutine của chính nó. Một panic trong bất kỳ goroutine nào không có recover sẽ giết cả tiến trình, bao gồm main và mọi goroutine khác.

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")
}

Hai dòng của worker có thể in ra theo thứ tự bất kỳ; main finished luôn ở cuối. Một defer recover() trong main sẽ không cứu được chương trình khỏi worker thứ hai. Đây là lý do máy chủ HTTP recover theo từng request: net/http recover các panic trong goroutine của mỗi handler, ghi log và đóng kết nối đó, để một request lỗi không đánh sập cả máy chủ.

Một số sự cố là fatal error, không phải panic, và hoàn toàn không recover được: concurrent map writes, hết bộ nhớ, và all goroutines are asleep của bộ phát hiện deadlock.

Khi nào panic là lựa chọn đúng

Nguyên tắc chung của Go: trả về lỗi cho mọi thứ có thể hỏng lúc chạy, và chỉ panic khi lập trình viên mắc lỗi. Cụ thể, panic phù hợp khi:

• Một bất biến bị phá vỡ. Một switch trên enum của chính bạn rơi vào trường hợp không thể xảy ra. Chạy tiếp sẽ làm hỏng dữ liệu.
• Một hàm hỗ trợ Must nhận đầu vào hằng số sai. regexp.MustCompile, template.Must và uuid.MustParse bọc một hàm trả về lỗi và panic khi thất bại. Hãy dùng chúng cho các giá trị biết trước lúc biên dịch, thường là biến cấp package, nơi thất bại có nghĩa là mã nguồn sai:

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

• Không thể khởi động tiếp. Thiếu cấu hình bắt buộc trong main. Ngay cả khi đó, in lỗi ra rồi gọi os.Exit(1) thường gọn gàng hơn một stack trace.

Panic là công cụ sai cho:

• Những thất bại lường trước được: đầu vào không hợp lệ của người dùng, thiếu tệp, hết thời gian chờ. Hãy trả về error; xem xử lý lỗi.
• Điều khiển luồng: dùng panic và recover như exception xuyên qua một cây lời gọi lớn khiến code khó theo dõi. Thư viện chuẩn làm vậy ở vài chỗ bên trong (bộ mã hóa của encoding/json), nhưng luôn recover trước khi trả về, nên không panic nào lọt ra khỏi package.
• API của thư viện: một thư viện panic khi gặp đầu vào sai buộc mọi nơi gọi phải thêm recover. Hãy trả về lỗi.

Lỗi thường gặp

• Gọi recover bên ngoài hàm được defer. Nó trả về nil.
• Recover trong main cho panic của một goroutine. Mỗi goroutine cần recover của riêng nó.
• Nuốt hết mọi panic. Ghi log kèm stack (debug.Stack() từ runtime/debug) và panic lại những gì bạn không lường trước.
• Dùng recover để xử lý việc ghi vào map nil hay chỉ số vượt phạm vi. Hãy sửa bug.