Exceptions ou valeurs de retour : repenser la gestion des erreurs

La gestion des erreurs est probablement l’un des aspects les plus mal utilisés en programmation. On retrouve généralement deux approches : lancer des exceptions, ou retourner des erreurs par des codes de retour.

Une distinction simple mais fondamentale

Dans des langages qui s’appuient beaucoup sur les exceptions, je suis venu, avec l’expérience et des lectures comme Code Complete, à une règle simple :

• Les exceptions devraient être réservées aux situations réellement exceptionnelles.
• Les erreurs fonctionnelles devraient être gérées par valeur de retour.

Une erreur de validation — un code postal invalide, par exemple — n’est pas exceptionnelle. C’est un scénario normal du domaine métier. Utiliser une exception dans ce cas brise le flux normal du programme, et c’est rarement performant.

À l’inverse, une base de données indisponible, une panne réseau ou une corruption de données : là, oui, on est dans l’exceptionnel.

L’approche de Go

Le langage Go adopte un parti pris différent : pas d’exceptions, toutes les erreurs sont des valeurs retournées.

res, msg, err := calculEtMessage(a, b)
if err != nil {
    fmt.Println("Erreur détectée :", err)
}

C’est plus verbeux, oui. Mais aussi plus explicite et plus simple. Surtout, cela force à traiter chaque erreur comme faisant partie du flux normal du programme. Autre avantage : la possibilité de retourner plusieurs valeurs, ce qui rend naturelle la gestion de l’erreur aux côtés du résultat.

Ce n’est pas une solution universelle, mais une approche qui mérite réflexion — surtout en architecture.