Les exceptions constituent les erreurs non prévisibles, comme un problème réseau, disque plein, et d'autres aspects, comme la sécurité. Je comprends mal l'intérêt de ne pas utiliser les exceptions..
Je ne suis pas d’accord. Si les interfaces que tu utilises sont correctement définies, tu dois pouvoir connaître la liste des exceptions. Donc, des erreurs. Récupérer une exception networkUnreachable ou une erreur NetworkUnreachable, je ne vois pas trop la différence.
Le principal intérêt des exceptions, àmha, dans les langages impératifs, c’est de pouvoir balancer l’erreur et la récupérer à l’endroit le plus propice, sans faire de cascade d’erreur, de cas particulier juste dans l’optique de la rebalancer à l’appelant. Le pendant de ça, c’est que rien ne garantit que quelqu’un récupère l’erreur.
Avec les types permettant le Railway programming, dans les langages fonctionnels, si tu ajoutes un cas d’erreur, tous les case, match où le type est utilisé doit être complet. Donc le compilateur te le dira si tu oublies de gérer un cas d’erreur.
[^] # Re: Kamoulox !
Posté par Anthony Jaguenaud . En réponse au journal Golang, oops you did it again. Évalué à 4.
Je ne suis pas d’accord. Si les interfaces que tu utilises sont correctement définies, tu dois pouvoir connaître la liste des exceptions. Donc, des erreurs. Récupérer une exception
networkUnreachableou une erreurNetworkUnreachable, je ne vois pas trop la différence.Le principal intérêt des exceptions, àmha, dans les langages impératifs, c’est de pouvoir balancer l’erreur et la récupérer à l’endroit le plus propice, sans faire de cascade d’erreur, de cas particulier juste dans l’optique de la rebalancer à l’appelant. Le pendant de ça, c’est que rien ne garantit que quelqu’un récupère l’erreur.
Avec les types permettant le Railway programming, dans les langages fonctionnels, si tu ajoutes un cas d’erreur, tous les
case,matchoù le type est utilisé doit être complet. Donc le compilateur te le dira si tu oublies de gérer un cas d’erreur.