Risposta.

Storia della domanda:

Gli operatori defer, panic e recover sono importanti meccanismi di gestione del flusso di esecuzione in Go. L'operatore defer viene utilizzato per l'esecuzione ritardata delle funzioni, panic innesca un errore (terminazione anomala), mentre recover consente di catturare l'errore e continuare l'esecuzione.

Problema:

Senza un'adeguata gestione di questi strumenti è difficile finalizzare correttamente le risorse e implementare la resilienza. La terminazione imprevedibile della funzione, le risorse non rilasciate e l'uscita incontrollata dell'applicazione in caso di errori sono problemi frequenti se non si adotta un approccio corretto.

Soluzione:

L'applicazione corretta di defer garantisce un rilascio sicuro delle risorse anche in caso di errori. panic è un meccanismo di arresto in situazioni anomale, che dovrebbe essere utilizzato solo per casi veramente eccezionali. recover offre la possibilità di "salvare" l'esecuzione all'interno di una funzione deferita.

Esempio di codice:

func riskyFunction() {
    defer func() {
        if r := recover(); r != nil {
            fmt.Println("Recovered in riskyFunction:", r)
        }
    }()
    fmt.Println("Doing some work...")
    panic("something bad happened!")
}

func main() {
    riskyFunction()
    fmt.Println("After riskyFunction")
}

Caratteristiche chiave:

defer viene sempre chiamato in ordine inverso prima dell'uscita dalla funzione. Anche in caso di panic.
recover funziona SOLO all'interno delle funzioni deferite.
panic interrompe l'esecuzione dell'attuale goroutine; se non catturato tramite recover, termina il processo.

Domande trabocchetto.

Perché recover non funziona al di fuori di defer all'interno della stessa funzione in cui si è verificato panic?

recover restituisce un valore non nullo (ovvero cattura il panic) solo se viene chiamato da una funzione deferita, annidata nella stessa funzione in cui si è verificato il panic. Se si chiama recover direttamente, restituirà sempre nil.

Esempio di codice:

func f() {
    panic("fail!")
    r := recover() // non funziona!
}

Si può chiamare defer dopo panic e questo verrà eseguito?

No. Dopo panic tutte le chiamate defer già registrate vengono eseguite, ma nuove defer dopo panic non verranno chiamate, poiché l'esecuzione della funzione è già "schiacciata".

Si può recuperare (recover) da panic avvenuta in un'altra goroutine?

No, recover funziona solo per panic nella goroutine attuale. Se un'altra goroutine va in panic e non viene chiamato recover in quella stessa goroutine, l'applicazione terminerà.

Errori comuni e anti-pattern

Utilizzare panic per la normale gestione degli errori.
Aspettarsi che recover "catturi" panic da tutte le parti del codice.
Confondere l'ordine di chiamata di più defer.

Esempi della vita reale

Caso negativo

Nel progetto tutti gli errori venivano sollevati attraverso panic, e la gestione del recovery avveniva solo nella funzione principale. Questo portava al fatto che le risorse non venivano chiuse, parte dei dati veniva persa e i log erano illeggibili.

Pro:

Sviluppo rapido, poco codice per la gestione degli errori.

Contro:

Comportamento imprevedibile del sistema, frequenti perdite, debug complesso.

Caso positivo

In ogni punto critico si utilizzava defer per rilasciare le risorse, panic veniva applicato solo a situazioni veramente eccezionali, e recover veniva utilizzato per isolare i guasti in parti non critiche. In questo modo venivano registrati tutti i dettagli dell'errore.