Odpowiedź.

W Go do gwarantowanego czyszczenia lub zakończenia pracy z zasobami używa się wywołań opóźnionych (defer) w połączeniu z anonimowymi zamknięciami (closures). Taki wzorzec pozwala grupować logikę czyszczenia i prawidłowo obsługiwać błędy, zapewniając czytelny i niezawodny kod.

Historia pytania:

Defer wzięto z innych języków i znacznie ułatwia życie programisty Go. Połączenie defer i zamknięcia stało się standardem w celu zapewnienia czyszczenia plików, połączeń i wszelkich zewnętrznych zasobów w blokach, gdzie może być wiele wyjść (return, panic).

Problem:

Przy złożonej logice czyszczenia zasobów (na przykład pliki, połączenia, lokacje) należy zapewnić, że nawet w przypadku błędu lub wyjścia z funkcji czyszczenie się odbędzie. Przy nieumiejętnym użyciu można uzyskać wycieki, nieprawidłowy porządek czyszczenia lub bezsensowne błędy.

Rozwiązanie:

Używać defer z anonimową funkcją (closure), aby:

Izolować zakres widoczności zmiennych,
Bezpiecznie obsługiwać błędy przy zamykaniu,
Zarządzać kumulacją wiadomości/zbieraniem śmieci.

Przykład kodu:

package main
import (
    "fmt"
    "os"
)

func WriteFileDemo(filename string) (err error) {
    f, err := os.Create(filename)
    if err != nil { return }
    defer func() {
        cerr := f.Close()
        if cerr != nil && err == nil {
            err = cerr
        }
    }()
    // Logika robocza z plikiem
    fmt.Fprintln(f, "Hello world")
    return // defer zostanie wykonany nawet jeśli tutaj jest return
}

func main() {
    if err := WriteFileDemo("test.txt"); err != nil {
        fmt.Println("Błąd:", err)
    }
}

Kluczowe cechy:

Opóźnione zamknięcia doskonale zarządzają czasem czyszczenia i przechwytują poprawny kontekst
Zapewniają ochronę przed wyciekami przy wielu wariantach wyjścia z funkcji
Prawidłowe działanie z błędami zależy od kolejności i czasu obliczania parametrów defer

Pytania z przekrętką.

Kiedy zmienne używane wewnątrz opóźnionego zamknięcia są utrwalane — w momencie deklaracji defer czy przy faktycznym wywołaniu?

Są utrwalane w momencie deklaracji defer, ale jeśli zamknięcie odnosi się do zmiennych przez referencję, użyte zostaną ich wartości w momencie wykonania defer. Czasami prowadzi to do nieoczekiwanych wyników.

for i := 0; i < 3; i++ {
    defer func() { fmt.Println(i) }() // wydrukuje 2, 2, 2
}

Czy można przekazywać wartości do zamknięcia przez parametry, aby uniknąć przechwytywania przez referencję?

Tak, można zadeklarować parametry dla anonimowej funkcji i przekazywać im bieżące wartości — wtedy wartości „zamrażają” się jako kopie.

for i := 0; i < 3; i++ {
    defer func(n int) { fmt.Println(n) }(i) // wydrukuje 2, 1, 0
}

Co zrobić, jeśli w opóźnionym zamknięciu wystąpi panika? Jak ją obsłużyć?

Wewnątrz zamknięcia należy użyć konstrukcji recover(), aby nie dopuścić do wyjścia paniki na zewnątrz i realizować łagodną naprawę funkcjonalności.

defer func() {
    if r := recover(); r != nil {
        log.Println("Odzyskano:", r)
    }
}()

Typowe błędy i antywzorce

Przechwytywanie zmiennych pętli przez referencję w opóźnionym zamknięciu
Niebranie pod uwagę błędów wewnątrz zamknięcia (błędy są tracone)
Naruszenie porządku wywołania defer (LIFO: ostatni defer jako pierwszy)

Przykład z życia

Negatywny przypadek

Kod otwiera kilka plików, ale zapomina umieścić defer f.Close(). W przypadku błędu zwraca kontrolę, a część plików pozostaje nieoczyszczona, pojawiają się wycieki zasobów.

Zalety:

Mniej kodu

Wady:

Wyciek pamięci lub deskryptorów plików, niestabilna praca

Pozytywny przypadek

Używa się opóźnionego zamknięcia dla wszystkich operacji sprzedażowych: starannie zamykając strumień plików i obsługując błąd, nawet jeśli plik nie został w pełni zapisany.