Réponse.

Historique de la question :

Les opérateurs defer, panic et recover sont des mécanismes importants pour gérer le flux d'exécution en Go. L'opérateur defer est utilisé pour l'exécution différée des fonctions, panic initie une erreur (arrêt d'urgence) et recover permet d'intercepter l'urgence et de continuer l'exécution.

Problème :

Sans une utilisation appropriée de ces outils, il est difficile de finaliser correctement les ressources et d'implémenter la résilience. La terminaison imprévisible d'une fonction, les ressources non libérées et la "sortie" incontrôlée de l'application en cas d'erreurs sont des problèmes fréquents avec une approche incorrecte.

Solution :

Une bonne utilisation de defer garantit la libération sécurisée des ressources même en cas d'erreurs. panic est un mécanisme d'arrêt d'urgence lors de situations exceptionnelles, qui ne devrait être utilisé que pour des cas vraiment exceptionnels. recover permet de "sauver" l'exécution à l'intérieur d'une fonction différée.

Exemple de code :

func riskyFunction() {
    defer func() {
        if r := recover(); r != nil {
            fmt.Println("Récupéré dans riskyFunction :", r)
        }
    }()
    fmt.Println("Effectuer un certain travail...")
    panic("quelque chose de mal est arrivé !")
}

func main() {
    riskyFunction()
    fmt.Println("Après riskyFunction")
}

Caractéristiques clés :

defer est toujours appelé dans l'ordre inverse avant la sortie de la fonction. Même en cas de panic.
recover fonctionne UNIQUEMENT à l'intérieur des fonctions différées.
panic interrompt l'exécution de la goroutine actuelle ; si elle n'est pas interceptée par recover, elle termine le processus.

Questions pièges.

Pourquoi recover ne fonctionne-t-il pas en dehors de defer à l'intérieur de la même fonction où la panic s'est produite ?

recover retourne une valeur non nulle (c'est-à-dire intercepte la panique) uniquement s'il est appelé depuis une fonction defer, imbriquée dans la même fonction où la panique s'est produite. Si recover est appelé directement, il retourne toujours nil.

Exemple de code :

func f() {
    panic("échec !")
    r := recover() // ne fonctionne pas !
}

Peut-on appeler defer après une panic et sera-t-il exécuté ?

Non. Après une panic, tous les appels defer déjà enregistrés sont exécutés, mais les nouveaux defer après panic ne seront pas appelés, car l'exécution de la fonction est déjà "compressée".

Peut-on se rétablir (recover) d'une panic survenue dans une autre goroutine ?

Non, recover ne fonctionne que pour les panics dans la goroutine actuelle. Si une autre goroutine panic et que l'appel à recover ne s'est pas produit dans cette même goroutine, l'application se termine.

Erreurs typiques et anti-modèles

Utiliser panic pour la gestion des erreurs habituelles.
S'attendre à ce que recover "attrape" la panique de toutes les parties du code.
Confondre l'ordre d'appel de plusieurs defer.

Exemple de la vie réelle

Cas négatif

Dans le projet, toutes les erreurs étaient lancées via panic, et la gestion de recovery n'était présente que dans la fonction principale. Cela entraînait la non-fermeture des ressources, la perte de certaines données et des logs illisibles.

Avantages :

Développement rapide, peu de code pour la gestion des erreurs.

Inconvénients :

Comportement imprévisible du système, fuites fréquentes, débogage compliqué.

Cas positif

Dans chaque section critique, defer était utilisé pour libérer des ressources, panic était utilisée uniquement pour des situations véritablement exceptionnelles, et recover était utilisé pour isoler les urgences dans des parties non critiques. Tous les détails de l'erreur étaient enregistrés.