defer: เปิดแล้วปิดให้ครบทุกทางออก

1 · ปัญหาที่ defer แก้

ลองดูโค้ดแบบไม่มี defer ก่อน — นับดูว่า Close() ต้องเขียนกี่ที

func readFile(name string) error {
    f, err := os.Open(name)
    if err != nil { return err }

    data := make([]byte, 100)
    n, err := f.Read(data)
    if err != nil {
        f.Close()          // ← 1
        return err
    }
    if n == 0 {
        f.Close()          // ← 2  (ลืมข้อนี้ = file leak)
        return errEmpty
    }
    f.Close()              // ← 3
    return nil
}

เขียนใหม่ด้วย defer:

func readFile(name string) error {
    f, err := os.Open(name)
    if err != nil {
        return err        // ยังไม่ได้เปิด → ไม่ต้องปิด
    }
    defer f.Close()       // ✓ เขียนครั้งเดียว ติดกับ Open เลย

    data := make([]byte, 100)
    n, err := f.Read(data)
    if err != nil { return err }   // Close ทำงานที่นี่
    if n == 0      { return errEmpty } // และที่นี่
    return nil                        // และที่นี่
}

2 · กฎ 3 ข้อ (จาก blog ทางการ)

Defer, Panic, and Recover ระบุกฎไว้ 3 ข้อพอดี ท่องให้ได้ทั้งสามข้อ

กฎ 1 — argument ถูกประเมิน ตอนบรรทัด defer ไม่ใช่ตอนทำงาน

"A deferred function's arguments are evaluated when the defer statement is evaluated."

func a() {
    i := 0
    defer fmt.Println(i)
    i++
    return
}

ถ้าอยากได้ค่า ล่าสุด ให้ห่อด้วย closure แทน:

i := 0
defer fmt.Println(i)                          // พิมพ์ 0  — ส่งค่าเข้าไป
defer func() { fmt.Println(i) }()          // พิมพ์ 1  — closure อ่านตอนทำงาน
i++

กฎ 2 — ทำงานแบบ LIFO หลังฟังก์ชัน return

"Deferred function calls are executed in Last In First Out order after the surrounding function returns."

func b() {
    for i := 0; i < 4; i++ {
        defer fmt.Print(i)
    }
}

LIFO (Last In First Out = เข้าทีหลัง ออกก่อน) ไม่ใช่เรื่องบังเอิญ — ของที่เปิดทีหลัง มักต้องปิดก่อน ดูตัวอย่างจริงจากงาน backend:

func processOrder(db *sql.DB) error {
    logFile, _ := os.OpenFile("log.txt", os.O_APPEND, 0644)
    defer logFile.Close()   // ประกาศก่อน → ทำทีหลังสุด

    tx, _ := db.Begin()
    defer tx.Rollback()    // ประกาศทีหลัง → ทำก่อน ✓ ถูกลำดับ

    if _, err := tx.Exec("INSERT INTO orders ..."); err != nil {
        return err          // rollback อัตโนมัติ
    }
    return tx.Commit()     // commit สำเร็จ → Rollback ที่ตามมากลายเป็น no-op
}

defer tx.Rollback() ทันทีหลัง Begin() แปลว่า "ถ้าไม่ commit สำเร็จ ให้ย้อนกลับ" — ไม่ต้องเขียน rollback ซ้ำในทุกจุดที่ return error

แล้วถ้า Commit() สำเร็จล่ะ — Rollback() ที่ตั้ง defer ไว้ ก็ยังทำงานอยู่ดีไม่ใช่เหรอ? ใช่ มันทำงานจริง แต่ไม่มีอะไรให้ย้อนแล้ว เพราะ transaction (กลุ่มคำสั่งฐานข้อมูลที่ต้อง "สำเร็จทั้งชุด หรือไม่ก็ยกเลิกทั้งชุด") หนึ่งชุดจบได้ครั้งเดียว

พอ commit ไปแล้ว Rollback() จะคืน error sql.ErrTxDone กลับมาเฉย ๆ แล้วไม่แตะฐานข้อมูลเลย เราจงใจไม่รับ error ตัวนั้น เพราะมันคือกรณีปกติที่คาดไว้อยู่แล้ว

กฎ 3 — deferred function แก้ named return value ได้

"Deferred functions may read and assign to the returning function's named return values."

func c() (i int) {        // ← ตั้งชื่อ return value ว่า i
    defer func() { i++ }()
    return 1
}

ใช้ทำอะไรจริง — ห่อ error ให้มีบริบทโดยไม่ต้องแก้ทุกจุด return:

func loadConfig(path string) (err error) {
    defer func() {
        if err != nil {
            err = fmt.Errorf("loadConfig %s: %w", path, err)
        }
    }()

    // ...มี return err อยู่ 5 จุด ทุกจุดจะถูกห่อให้อัตโนมัติ
}

%w คือ verb พิเศษที่มีเฉพาะใน fmt.Errorf (verb = ตัวอักษรที่ตามหลัง % ซึ่งบอกว่าค่าตรงนั้นจะพิมพ์ออกมาแบบไหน) หน้าตา output ของมันเหมือน %v ทุกอย่าง แต่มันเก็บ error ตัวเดิมติดไปด้วย ทำให้โค้ดชั้นบนยังตรวจได้ว่า "ข้างในมัน error ตัวไหนกันแน่" ถ้าใช้ %v ข้อความจะเหมือนกันเป๊ะแต่ error ตัวเดิมหายไป เหลือแค่ตัวหนังสือ เวลาห่อ error ให้ใช้ %w เสมอ

3 · 2 กับดักที่ต้องรู้

// ❌ เปิด file 1000 ตัวค้างพร้อมกัน
for _, name := range files {
    f, _ := os.Open(name)
    defer f.Close()
}

// ✓ ครอบด้วยฟังก์ชันย่อย → จบทุกรอบ
for _, name := range files {
    func() {
        f, _ := os.Open(name)
        defer f.Close()
        // ...
    }()
}

defer fmt.Println("จะไม่ถูกพิมพ์")
log.Fatal("boom")   // = log.Print + os.Exit(1) → ตายทันที

4 · ทดสอบความจำ

5 · ลงมือทำ

อ่านต่อจากต้นทาง

แหล่งหลักที่แนะนำ: Defer, Panic, and Recover — สั้นมาก อ่าน 6 นาทีจบ ส่วนท้ายว่าด้วย recover ยังไม่ต้องอ่านลึก แต่ให้รู้ว่ามีอยู่

อ้างอิง

• Defer, Panic, and Recover — กฎ 3 ข้อ พร้อมตัวอย่าง a(), b(), c() ที่ยกมาในบทนี้
• Go spec — Defer statements — พฤติกรรมตอน panic และการคลาย stack
• Go Code Review Comments — Don't Panic, Indent Error Flow