[BP#47] Eviter d'utiliser try-catch-finally

[devcrafting]

Cette BP n'est pas spécifique au JS. Cela a d'ailleurs aussi un effet "performance" souvent décrié (même si je trouve qu'on dans de l'optimisation prématurée quand on en parle sous cet axe).
Par contre élément très intéressant : la programmation fonctionnelle pousse à expliciter les valeurs de retour, notamment avec les types Option/Maybe, Result/Either, Promise, Future...
NB: non limitée aux languages fonctionnels, Java, JS, C#...poussent aussi cela. Il me semble intéressant de le mentionner.

[ACTLEM]

L'intérêt des Either est aussi que cela permet de structurer les cas d'exceptions. Le problème avec un catch générique est que cela décharge souvent d'une réflexion sur la gestion des erreurs si bien que l'on arrive fréquemment à un comportement non attendu pour l'utilisateur. Bref, je suis d'accord pour mentionner ce qui se fait en programmation fonctionnelle.

[tbroyer]

Si je comprend bien la BP, il s'agit d'éviter le coût d'une exception (qui inclue la collecte de la stacktrace, bien plus que la "création d'une variable") quand elle peut être évitée: au lieu d'accéder à un tableau/une liste et gérer une IndexOutOfBoundsException, il vaut mieux vérifier auparavant si l'index est valide par exemple (si c'est un cas qu'on veut gérer bien sûr); bref, laisser les exceptions aux cas exceptionnels et ne pas les utiliser comme une structure de contrôle comme une autre.

Mais j'ai tendance à penser qu'on s'approche dans tous les cas de la micro-optimisation et/ou de la qualité du code, et pas vraiment de l'écoconception.

[devcrafting]

Peut-être bien proche de la micro-optimisation, sauf si c'est trop utilisé. Et en effet, plus une question de qualité de code

[ACTLEM]

Oui cela touche la qualité de code qui est aussi un élément de l'écoconception web car une mauvaise qualité implique plus de maintenance, et donc plus de ressources humaines et matérielles pour gérer la dette occasionnée (support, correctif, déploiement...).
Sinon, je suis pour la reformuler et mieux la contextualiser.

[ACTLEM]

@devcrafting la tendance est plutôt est à la suppression de cette bonne pratique. Veux-tu organiser un point pour proposer une alternative cette bonne pratique ou directement préciser comment tu verrais une bonne pratique sur le sujet abordé dans cette discussion stp?

[devcrafting]

Hum je ne sais pas, je le vois comme un potentiel problème quand c'est utilisé à tord et à travers (pour gérer des cas métiers), et c'est à ce titre que c'est intéressant de le mentionner et de mentionner les possibilités de modélisation (notamment issu de la programmation fonctionnelle)
Mais sinon je suis d'accord que si c'est pour éviter quelques try/catch cela relève de la micro-optimisation

[ACTLEM]

J'ai créé l'issue pour suppression: #246

N'hésite pas à proposer une nouvelle discussion (d'ici e 19/11) autour de la gestion des exceptions/cas d'erreurs en mentionnant la programmation fonctionnelle. Peut-être un truc du genre "Eviter de remonter des exceptions à l'utilisateur" (et donc des ressources utilisées pour rien) même si cela rejoint la qualité de code, le fait qu'elle soit un peu plus générique et qu'avoir une BP autour de la qualité me paraîtrait pas mal.