defer, la promesse différée defer, the deferred promise

defer planifie du code pour la sortie de la fonction — quelle que soit la façon dont elle sort.defer schedules code for the function's exit — whatever way it exits.

On ouvre un volume nouveau. Jusqu'ici, on a parlé d'espace — où vit une valeur, qui la possède, qui peut la changer. defer parle de temps : il déplace un bout de code dans le futur, à l'instant précis où la fonction se terminera. Sa promesse est simple et puissante : tu écris defer suivi d'un appel, et cet appel ne s'exécute pas tout de suite — il est mis de côté, et Go garantit de le lancer juste avant que la fonction ne rende la main, quel que soit le chemin emprunté pour sortir. Un return en début de fonction, un return après une erreur, un return tout au fond, et même un panic qui déroule la pile : dans tous les cas, le code différé s'exécute. C'est exactement ce qu'il faut pour gérer les ressources. Une ressource qu'on acquiert — un fichier ouvert, un verrou pris, une connexion établie — doit toujours être libérée, et le drame habituel est d'oublier cette libération sur l'un des nombreux chemins de sortie d'une fonction. defer supprime le problème à la racine : on écrit la libération juste après l'acquisition, sur la ligne d'à côté, et on n'y pense plus. Acquérir puis defer libérer, collés l'un à l'autre, est l'un des motifs les plus reconnaissables du Go idiomatique. Le code différé est lisible là où il compte — près de ce qu'il nettoie — et il s'exécute là où il faut — à la toute fin, sans exception.We open a new volume. So far, we've spoken of space — where a value lives, who owns it, who can change it. defer speaks of time: it moves a piece of code into the future, to the precise instant the function ends. Its promise is simple and powerful: you write defer followed by a call, and that call doesn't run right away — it's set aside, and Go guarantees to launch it just before the function returns, whatever path was taken to exit. A return early in the function, a return after an error, a return deep at the bottom, and even a panic unwinding the stack: in every case, the deferred code runs. That's exactly what's needed to manage resources. A resource you acquire — an open file, a held lock, an established connection — must always be released, and the usual tragedy is forgetting that release on one of a function's many exit paths. defer removes the problem at the root: you write the release right after the acquisition, on the next line, and you stop thinking about it. Acquire then defer release, glued together, is one of the most recognizable patterns of idiomatic Go. The deferred code is readable where it matters — near what it cleans up — and it runs where it must — at the very end, no exception.

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

    data, err := parse(f)
    if err != nil {
        f.Close()              // … qu'il faut penser à fermer ici …
        return err
    }
    if data.empty() {
        f.Close()              // … et ici …
        return ErrEmpty
    }
    f.Close()                  // … et ici. Un seul oubli, et le fichier fuit.
    return nil
}

func process(path string) error {
    f, err := os.Open(path)
    if err != nil {
        return err
    }
    defer f.Close()            // planifié MAINTENANT, exécuté à la SORTIE

    data, err := parse(f)
    if err != nil {
        return err             // f.Close() aura lieu, automatiquement
    }
    if data.empty() {
        return ErrEmpty        // … ici aussi …
    }
    return nil                 // … et ici. Un seul Close, pour tous les chemins.
}