Évitez de vérifier si l'erreur est nulle ?

Question

Je suis actuellement en train d'apprendre go et une partie de mon code ressemble à ceci :

a, err := doA()
if err != nil {
  return nil, err
}
b, err := doB(a)
if err != nil {
  return nil, err
}
c, err := doC(b)
if err != nil {
  return nil, err
}
... et ainsi de suite ...

Cela me semble un peu faux car la vérification des erreurs prend la plupart des lignes. Existe-t-il un moyen plus efficace de gérer les erreurs ? Serait-il possible d'éviter cela en refactorisant ?

MISE À JOUR : Merci pour toutes les réponses. Veuillez noter que dans mon exemple, doB dépend de a, doC dépend de b, et ainsi de suite. Par conséquent, la plupart des refontes suggérées ne fonctionnent pas dans ce cas. Une autre suggestion ?

Answer 1

Il semble incorrect pour vous peut-être parce que vous avez l'habitude de ne pas gérer les erreurs au niveau de l'appel. C'est assez idiomatique pour Go mais cela ressemble à beaucoup de code redondant si vous n'y êtes pas habitué.

Cela comporte cependant quelques avantages.

1. vous devez réfléchir à la manière appropriée de gérer cette erreur à l'endroit où l'erreur a été générée.
2. Il est facile de lire le code pour voir à chaque point où le code va s'arrêter et retourner prématurément.

Si cela vous dérange vraiment, vous pouvez être créatif avec des boucles for et des fonctions anonymes mais cela devient souvent compliqué et difficile à lire.