Renvoyer un optionnel, par exemple, va m'empêcher de chaîner les appels, et va me forcer à écrire beaucoup de boilerplate moche, à moins de n'avoir que des optionnels partout (bonjour la complexité pour vérifier chaque optionnel au début de chaque fonction, sans compter l'impact sur les perfs).
Heu, ouais, mais si t’as pas d’élément le plus grand, il va bien falloir gérer ça quelque part quand même. Soit tu gères ça au call site (voir le call site du call site), soit tu laisses ça remonter en mode « quelqu’un d’autre peut pas l’faire?!? ».
Dans le premier cas, t’es pas dans une semantique d’exception, mais de gestion de code d’erreur. Le compilateur peut t’aider si le langage a un support avancé de ce genre de choses, mais au final, la problématique est surtout « cosmétique »: comment écrire le code de facon concise et lisible. Utiliser des exceptions parce que ça te permet de try/catcher au call site plutôt qu’un if return, c’est un peu bourrin. Et surtout, ça va pas fondamentalement résoudre le problème si le call site risque de se prendre plus d’une exception. Même topo si tes call stacks sont très profondes: t’as un très probablement un problème architectural. Si tu viens me dire qu’un if/return est trop cher, ma réponse va être: j’en doute, en tout cas pas sans un benchmark sérieux montrant un impact concret (pas un benchmark qui cherry pick « 50% mieux », en omettant de dire que les 50% mieux, c’est 2ms, ou 0.1% du temps d’exécution total).
Dans le deuxième cas, c’est très précisément ce qu’il ne faut PAS faire avec des exceptions. Les laisser remonter dans une couche qui n’est même pas au courant que les couches inférieures existent.
[^] # Re: Pas de fumée sans feu
Posté par groumly . En réponse au journal De l'influence néfaste de Google sur les développeurs C++. Évalué à 5.
Heu, ouais, mais si t’as pas d’élément le plus grand, il va bien falloir gérer ça quelque part quand même. Soit tu gères ça au call site (voir le call site du call site), soit tu laisses ça remonter en mode « quelqu’un d’autre peut pas l’faire?!? ».
Dans le premier cas, t’es pas dans une semantique d’exception, mais de gestion de code d’erreur. Le compilateur peut t’aider si le langage a un support avancé de ce genre de choses, mais au final, la problématique est surtout « cosmétique »: comment écrire le code de facon concise et lisible. Utiliser des exceptions parce que ça te permet de try/catcher au call site plutôt qu’un if return, c’est un peu bourrin. Et surtout, ça va pas fondamentalement résoudre le problème si le call site risque de se prendre plus d’une exception. Même topo si tes call stacks sont très profondes: t’as un très probablement un problème architectural. Si tu viens me dire qu’un if/return est trop cher, ma réponse va être: j’en doute, en tout cas pas sans un benchmark sérieux montrant un impact concret (pas un benchmark qui cherry pick « 50% mieux », en omettant de dire que les 50% mieux, c’est 2ms, ou 0.1% du temps d’exécution total).
Dans le deuxième cas, c’est très précisément ce qu’il ne faut PAS faire avec des exceptions. Les laisser remonter dans une couche qui n’est même pas au courant que les couches inférieures existent.