panic ו-recover ב-Go: panics בזמן ריצה ומתי להשתמש ב-panic

איך panic נראה

panic עוצר את הפונקציה הנוכחית, מריץ את הקריאות שלה שנדחו עם defer, ואז עושה את אותו הדבר בפונקציה שקראה לה, וכך הלאה במעלה המחסנית. אם הוא מגיע לראש ה-goroutine, התוכנית קורסת.

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

התוכנית הזאת יוצאת עם סטטוס 2. הפלט הוא:

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

הקריאה שנדחתה רצה לפני דוח הקריסה. ה-trace מציין את ה-goroutine, את הפונקציה ואת השורה, ובדרך כלל זה מספיק כדי למצוא את הבאג.

panics נפוצים בזמן ריצה

כל אחד מאלה הוא באג בתוכנית, לא מצב שצריך לטפל בו. התיקון הוא בדיקת גבולות, בדיקת nil, make או assertion עם comma-ok, לא recover.

התאוששות עם recover

recover() עוצרת panic. היא עובדת רק כשקוראים לה ישירות בתוך פונקציה שנדחתה עם defer, כי פונקציות כאלה הן הקוד היחיד שרץ בזמן ש-panic מגולל את המחסנית.

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

פלט:

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

מה קרה בקריאה השנייה:

1. a / b נכנס ל-panic.
2. ה-closure שנדחתה רצה, ו-recover() החזירה את ערך ה-panic (runtime.Error).
3. הגלילה נעצרה. safeDivide חזרה כרגיל ל-main, עם התוצאה בעלת השם err שה-closure קבעה.

התוצאה בעלת השם היא מה שמאפשר לפונקציה שנדחתה להחזיר שגיאה. בלעדיה, הפונקציה מחזירה את ערכי האפס שלה. העמוד על defer מסביר איך closures שנדחו משנות תוצאות.

recover() מחזירה nil כשאין panic, ולכן הבדיקה if r != nil הופכת את הפונקציה שנדחתה לבלתי מזיקה במסלול הרגיל. אם קוראים ל-recover מחוץ לפונקציה שנדחתה, או בפונקציה שהפונקציה שנדחתה קוראת לה, היא מחזירה nil ולא עושה כלום.

panic עם ערך משלכם

panic מקבלת כל ערך. שגיאה או מחרוזת הן הבחירה הרגילה.

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

בצעו recover למה שאתם מצפים לו, והפעילו panic מחדש לכל דבר אחר. בליעה של כל panic מסתירה באגים אמיתיים.

מאז Go 1.21, panic(nil) הופך ל-*runtime.PanicNilError, כך ש-recover() שמחזירה nil אומרת עכשיו באופן אמין "אין panic".

panics ב-goroutines

recover תופסת רק panics ב-goroutine שלה. panic בכל goroutine בלי recover הורג את כל התהליך, כולל main וכל שאר ה-goroutines.

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

שתי השורות של ה-workers יכולות להופיע בכל סדר; main finished תמיד מגיעה אחרונה. defer recover() ב-main לא היה מציל את התוכנית מה-worker השני. זו הסיבה ששרתי HTTP מבצעים recover לכל בקשה: net/http תופסת panics בכל goroutine של handler, רושמת אותם ללוג וסוגרת את החיבור הזה, כך שבקשה גרועה אחת לא מפילה את השרת.

חלק מהכישלונות הם שגיאות פטאליות, לא panics, ואי אפשר להתאושש מהם בכלל: concurrent map writes, מחסור בזיכרון, וה-all goroutines are asleep של מזהה ה-deadlock.

מתי panic הוא הבחירה הנכונה

הכלל הכללי של Go: החזירו שגיאות לכל דבר שיכול להשתבש בזמן ריצה, והשתמשו ב-panic רק לטעויות של המתכנת. באופן קונקרטי, panic מתאים כש:

• אינווריאנט נשבר. switch על enum משלכם מגיע למקרה שלא יכול לקרות. המשך הריצה היה משחית נתונים.
• פונקציית עזר מסוג Must מקבלת קלט קבוע לא תקין. regexp.MustCompile, template.Must ו-uuid.MustParse עוטפות פונקציה שמחזירה שגיאה ונכנסות ל-panic בכישלון. השתמשו בהן לערכים שידועים בזמן קומפילציה, בדרך כלל משתנים ברמת החבילה, שבהם כישלון אומר שקוד המקור שגוי:

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

• האתחול לא יכול להמשיך. הגדרה נדרשת חסרה ב-main. גם כאן, הדפסת השגיאה וקריאה ל-os.Exit(1) לרוב נקיות יותר מ-stack trace.

panic הוא הכלי הלא נכון ל:

• כישלונות צפויים: קלט לא תקין ממשתמש, קובץ חסר, timeout. החזירו error; ראו טיפול בשגיאות.
• בקרת זרימה: שימוש ב-panic וב-recover כמו ב-exceptions לאורך עץ קריאות גדול הופך את הקוד לקשה למעקב. הספרייה הסטנדרטית עושה את זה פנימית בכמה מקומות (ה-encoder של encoding/json), ותמיד מבצעת recover לפני שהיא חוזרת, כך ששום panic לא יוצא מהחבילה.
• APIs של ספריות: ספרייה שנכנסת ל-panic על קלט לא תקין מכריחה כל קוד קורא להוסיף recovers. החזירו שגיאה.

טעויות נפוצות

• קריאה ל-recover מחוץ לפונקציה שנדחתה. היא מחזירה nil.
• recover ב-main בשביל panic של goroutine. כל goroutine צריכה recover משלה.
• בליעה של כל ה-panics. רשמו ללוג עם המחסנית (debug.Stack() מ-runtime/debug) והפעילו panic מחדש למה שלא ציפיתם לו.
• שימוש ב-recover כדי לטפל בכתיבות ל-map שהוא nil או באינדקסים מחוץ לטווח. תקנו את הבאג במקום זה.