Go言語のpanicとrecover：実行時panicとpanicすべき場面

panicはどう見えるか

panicは現在の関数を止めてそのdeferした呼び出しを実行し、次にその呼び出し元で同じことをし、というようにスタックを上っていきます。ゴルーチンの一番上まで到達すると、プログラムはクラッシュします。

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

deferした呼び出しは、クラッシュの報告の前に実行されました。トレースにはゴルーチン、関数、行が示されており、たいていはそれでバグを見つけられます。

よくある実行時panic

どれも、処理すべき状態ではなくプログラムのバグです。直し方は recover ではなく、範囲チェック、nilチェック、make、カンマokのアサーションです。

回復する

recover() はpanicを止めます。panicが巻き戻っている間に実行されるコードはdeferした関数だけなので、deferした関数の中で直接呼んだときにしか機能しません。

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

2回目の呼び出しで起きたことは次のとおりです。

1. a / b がpanicした。
2. deferしたクロージャが実行され、recover() がpanicの値（runtime.Error）を返した。
3. 巻き戻しが止まった。safeDivide は、クロージャが設定した名前付き戻り値 err とともに、main へ普通に戻った。

deferした関数がエラーを返せるのは、名前付き戻り値があるからです。なければ関数はゼロ値を返します。deferしたクロージャが戻り値を変更する仕組みはdeferのページで扱っています。

panicがないとき recover() は nil を返すので、if r != nil のチェックによって、deferした関数は通常の経路では何もしません。deferした関数の外や、deferした関数から呼ばれた関数の中で呼ぶと、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))
}

想定しているものだけを回復し、それ以外は再びpanicさせます。すべてのpanicを握りつぶすと、本物のバグが隠れます。

Go 1.21以降、panic(nil) は *runtime.PanicNilError に変換されるので、recover() が nil を返せば確実に「panicはない」という意味になりました。

ゴルーチンの中のpanic

recover が捕まえるのは、自分のゴルーチンのpanicだけです。recoverのないゴルーチンでpanicが起きると、main や他のすべてのゴルーチンを含め、プロセス全体が終了します。

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

2つのワーカーの行はどちらの順でも表示されえますが、main finished は常に最後です。main の中の defer recover() では、2つ目のワーカーからプログラムを救えなかったでしょう。HTTPサーバーがリクエストごとにrecoverするのはこのためです。net/http は各ハンドラのゴルーチンでpanicを回復してログに出し、その接続を閉じるので、1つの不正なリクエストでサーバーが落ちることはありません。

失敗の中にはpanicではなく致命的エラーで、まったく回復できないものもあります。concurrent map writes、メモリ不足、そしてデッドロック検出器の all goroutines are asleep です。

panicするのが正しい場面

Goの一般的なルールは、実行時に起こりうることにはすべてエラーを返し、panicはプログラマーの間違いのときだけにする、というものです。具体的には、panicが適切なのは次のようなときです。

• 不変条件が壊れた。 自分の列挙型に対する switch が、起こりえないケースに到達した。続行するとデータが壊れます。
• Must ヘルパーが不正な定数の入力を受け取った。 regexp.MustCompile、template.Must、uuid.MustParse はエラーを返す関数を包み、失敗するとpanicします。コンパイル時にわかっている値、典型的にはパッケージレベルの変数に使います。そこでの失敗はソースコードが間違っていることを意味します。

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

• 起動を続けられない。 main で必須の設定がない場合です。ただ、ここでもスタックトレースより、エラーを表示して os.Exit(1) を呼ぶほうがすっきりすることが多いです。

panicが間違った道具なのは次のようなときです。

• 想定される失敗：不正なユーザー入力、存在しないファイル、タイムアウト。error を返します。エラー処理のページを参照してください。
• 制御の流れ：大きな呼び出しツリーをまたいでpanicとrecoverを例外のように使うと、コードを追いにくくなります。標準ライブラリは内部でいくつかの場所（encoding/json のエンコーダー）でこれを使っていますが、常に返す前に回復しているので、パッケージの外にpanicが漏れることはありません。
• ライブラリのAPI：不正な入力でpanicするライブラリは、すべての呼び出し側にrecoverを加えることを強います。エラーを返します。

よくある間違い

• deferした関数の外でrecoverを呼ぶ。 nil を返します。
• ゴルーチンのpanicに対して main でrecoverする。 各ゴルーチンに専用のものが必要です。
• すべてのpanicを握りつぶす。 スタック（runtime/debug の debug.Stack()）とともにログに出し、想定していなかったものは再びpanicさせます。
• nilマップへの書き込みや範囲外のインデックスを recover で扱う。 代わりにバグを直します。