Pièges Go pour débutants : 5 erreurs qui transforment votre code en enfer

Formateur Python en ligne pour débutants

Apprenez Python facilement sans surcharge théorique. Résolvez des tâches pratiques avec vérification automatique et écrivez du code directement dans le navigateur.

Start Course

Pourquoi Go semble simple mais piège les débutants ?

\n\n

Go (ou Golang) est un langage créé dans un seul but : que les programmeurs souffrent moins. Syntaxe minimaliste, concurrence intégrée, compilation rapide — il semble qu'on puisse l'apprendre en une semaine. Et oui, on peut l'apprendre. Mais « écrire du bon code » et « écrire du code en Go » sont deux histoires différentes.

\n\n

Les débutants apportent souvent leurs habitudes de Python, JavaScript ou Java et essaient de les plaquer sur Go. Résultat : des bugs difficiles à détecter, des paniques à l'exécution et le sentiment que « Go est cassé ». Spoiler : Go n'est pas cassé. Il pense simplement différemment.

\n\n

Dans cet article, nous allons analyser les 5 erreurs les plus fréquentes lors de l'apprentissage de Go. Si vous débutez — lisez attentivement. Si vous écrivez déjà en Go — vérifiez si vous ne les commettez pas encore.

\n\n

Erreur n°1 : Ignorer les erreurs (et l'habitude de Python)

\n\n

En Python ou JavaScript, vous avez l'habitude qu'une fonction puisse retourner un résultat ou lever une exception. Vous encadrez l'appel avec try/catch et vous vivez tranquille. En Go, c'est différent : il n'y a pas d'exceptions. Il n'y a que des valeurs de retour, et l'une d'elles est l'erreur.

\n\n

L'erreur la plus courante des débutants est d'écrire result, _ := someFunc() et d'oublier l'erreur. Ou, pire encore, de simplement ne pas la vérifier :

\n\n
// MAUVAIS : l'erreur est ignorée\nfile, _ := os.Open("config.yaml")\n// Si le fichier n'existe pas — file == nil, et la ligne suivante plantera avec une panique\ndefer file.Close()\n
\n\n

En Go, l'erreur n'est pas quelque chose d'effrayant. C'est juste une valeur. Il faut la vérifier. Toujours. Sans exception.

\n\n

Comment faire correctement ?

\n\n
// BON : on vérifie l'erreur immédiatement\nfile, err := os.Open("config.yaml")\nif err != nil {\n    log.Fatalf("impossible d'ouvrir le fichier : %v", err)\n}\ndefer file.Close()\n
\n\n

Ce n'est pas de la paranoïa. C'est de la discipline. Go vous apprend à être minutieux. Si vous ignorez une erreur en production — préparez-vous à ce qu'à 3 heures du matin, le service tombe et que les logs soient silencieux.

\n\n

Conseil : n'utilisez jamais _ pour une erreur, sauf si vous êtes sûr à 100% qu'elle ne se produira jamais. Et de telles situations n'existent quasiment pas dans le code réel.

\n\n

Erreur n°2 : Paniquer là où il faudrait une erreur

\n\n

En Go, il existe le mécanisme panic et recover. Les débutants les confondent souvent avec les exceptions et se mettent à paniquer pour le moindre problème. C'est une erreur.

\n\n

panic est un arrêt d'urgence du programme. Il est destiné aux situations où la poursuite de l'exécution est impossible : par exemple, le déréférencement d'un pointeur nul ou un dépassement de tableau. Utiliser panic pour gérer la logique métier est un mauvais usage.

\n\n
// MAUVAIS : panique au lieu d'une erreur\nfunc divide(a, b int) int {\n    if b == 0 {\n        panic("division par zéro !")\n    }\n    return a / b\n}\n
\n\n

La bonne approche est de retourner une erreur :

\n\n
// BON : on retourne une erreur\nfunc divide(a, b int) (int, error) {\n    if b == 0 {\n        return 0, fmt.Errorf("division par zéro")\n    }\n    return a / b, nil\n}\n
\n\n

Utilisez panic uniquement pour les situations vraiment critiques. Tout le reste, ce sont des erreurs. Go vous donne error pour une bonne raison.

\n\n

Erreur n°3 : Mauvaise gestion des goroutines et absence de synchronisation

\n\n

Les goroutines sont sans doute la fonctionnalité la plus cool de Go. Mais c'est aussi la plus dangereuse pour les débutants. Scénario typique : vous lancez 1000 goroutines, écrivez dans une variable partagée — et vous obtenez une course aux données (data race).

\n\n
// MAUVAIS : course aux données\nvar counter int\nfor i := 0; i < 1000; i++ {\n    go func() {\n        counter++ // pas sécurisé !\n    }()\n}\ntime.Sleep(time.Second)\nfmt.Println(counter) // résultat imprévisible\n
\n\n

Pourquoi est-ce un problème ? Parce que counter++ n'est pas une opération atomique. Elle consiste en une lecture, une incrémentation et une écriture. Deux goroutines peuvent lire la même valeur, l'incrémenter

Blogs

Book Recommendations