l'aspect performance, on ne retourne pas directement un résultat, mais un objet virtuel, qui contient soit le résultat, soit une erreur. C'est un inconvénient par rapport au fait de dissocier le résultat et l'erreur ;
Je sais pas trop ce que tu veux dire par « aspect performance », mais lancer une exception c’est loin d’être cheap, le stack unwinding, capturer la stack trace etc a un coût certain. En pratique, pour beaucoup d’application, ça va pas faire une différence notable, mais c’est pas gratuit, que ce soit en c++ ou en java.
A l’inverse, retourner un struct avec erreur xor résultat ne coute presque rien, c’est traité comme un return de base, que tu doit bien faire à un moment ou un autre.
Le coût de performance se transfère surtout sur la façon d’écrire le code, et la, t’as 2 approches, grosse modo:
ne pas abstraire le mécanisme, et laisser le développeur gérer ça « à la mano », avec un switch/case ou un if (result.error) (ce qui peut vite devenir assez moche en fonction du code que t’écrit),
abstraire le mécanisme, en prétendant que c’est une vraie exception, mais laisser le compilo gérer le sucre syntaxique pour traduire ça en if (result.error) goto exceptionHandlingBlock. C’est ce que fait Swift notamment, avec un try/catch qui n’est qu’une façon de différencier le cas d’erreur du cas normal au niveau syntaxique, mais en utilisant un Result sous le capot.
[^] # Re: Kamoulox !
Posté par groumly . En réponse au journal Golang, oops you did it again. Évalué à 5.
Je sais pas trop ce que tu veux dire par « aspect performance », mais lancer une exception c’est loin d’être cheap, le stack unwinding, capturer la stack trace etc a un coût certain. En pratique, pour beaucoup d’application, ça va pas faire une différence notable, mais c’est pas gratuit, que ce soit en c++ ou en java.
A l’inverse, retourner un struct avec erreur xor résultat ne coute presque rien, c’est traité comme un return de base, que tu doit bien faire à un moment ou un autre.
Le coût de performance se transfère surtout sur la façon d’écrire le code, et la, t’as 2 approches, grosse modo:
if (result.error)(ce qui peut vite devenir assez moche en fonction du code que t’écrit),if (result.error) goto exceptionHandlingBlock. C’est ce que fait Swift notamment, avec un try/catch qui n’est qu’une façon de différencier le cas d’erreur du cas normal au niveau syntaxique, mais en utilisant un Result sous le capot.