En Go, le pattern c'est de retourner (resultat, erreur). Si tu ne verifies pas l'erreur, dommage le compilateur ne t'aidera pas à t'en rendre compte.
Tu peux utiliser des linters et notamment le metalinter golangci-lint qui fait référence et évitera ce genre d'erreur (entre autres).
En plus il faut toujours gérer 4 cas: (result, nil), (result, err), (nil, err), (nill, nil). Et si les cas 2 et 4 semble improbables et inutiles, il n'y a pas besoin de chercher très loin dans la doc de la lib standard pour trouver des exemples (read par exemple, qui peut retourner des données et un EOF).
Euh, non pas spécialement, si tu retournes la valeur et non son pointeur donc (résultat, erreur) et pas (*résultat, erreur), tu ne peux pas avoir tes deux derniers cas (nil, err) et (nil, nil). Car tu disposeras directement de la valeur qui ne peut être nulle.
Après plus de 6 années d'expérience intensive de programmation en Go, mes fonctions ne retournent pratiquement que des valeurs donc (result,error). Si je dois retourner un pointeur, c'est qu'il y a un besoin bien particulier comme retourner une structure avec un partage d'un espace mémoire (ex : mutex et co).
[^] # Re: Raisons d'essayer Rust
Posté par woffer 🐧 (site web personnel) . En réponse au journal Retour d'expérience sur les langages de programmation. Évalué à 3.
Tu peux utiliser des linters et notamment le metalinter golangci-lint qui fait référence et évitera ce genre d'erreur (entre autres).
Euh, non pas spécialement, si tu retournes la valeur et non son pointeur donc (résultat, erreur) et pas (*résultat, erreur), tu ne peux pas avoir tes deux derniers cas (nil, err) et (nil, nil). Car tu disposeras directement de la valeur qui ne peut être nulle.
Après plus de 6 années d'expérience intensive de programmation en Go, mes fonctions ne retournent pratiquement que des valeurs donc (result,error). Si je dois retourner un pointeur, c'est qu'il y a un besoin bien particulier comme retourner une structure avec un partage d'un espace mémoire (ex : mutex et co).