Quand tu lis la documentation d'une fonction, si elle retourne un Result, tu peux tout de suite savoir les cas d'échec possibles. Et le système de type du langage peut vérifier que tout les cas sont gérés.
C'est pas le cas avec les exceptions. Les throws que tu fais ne font pas partie de la signature de la fonction.
Les exceptions sont une forme de early return, souvent comparé à goto. Pour ma part je trouve les 2 concepts complémentaire, cf Elixir ou on utilise {:ok, val} ou {:error, reason} pour ce qui est prévisible et raise / rescue pour ce qui ne l'est pas.
Dans certains cas je peux considérer qu'une requête HTTP qui retourne une 404 est prévisible mais qu'un network unreachable ne l'est pas : est-ce que la ressource existe ?
Dans d'autres cas, je considère que toute erreur est imprévisible : j'ai besoin de tel document
Dans le premier cas, si je reçois un {:error, 404} je peux retourner false et laisser l'exception network unreachable se propager.
Dans le second cas je transforme le {:error, reason} en exception (unwrap).
Les Result et les exceptions permettent tout deux de séparer le code et la gestion d'erreur, mais la sémantique, les performances, et l'intégration au système de type sont radicalement différent.
[^] # Re: Kamoulox !
Posté par David Delassus (site web personnel) . En réponse au journal Golang, oops you did it again. Évalué à 5.
Quand tu lis la documentation d'une fonction, si elle retourne un Result, tu peux tout de suite savoir les cas d'échec possibles. Et le système de type du langage peut vérifier que tout les cas sont gérés.
C'est pas le cas avec les exceptions. Les throws que tu fais ne font pas partie de la signature de la fonction.
Les exceptions sont une forme de early return, souvent comparé à goto. Pour ma part je trouve les 2 concepts complémentaire, cf Elixir ou on utilise
{:ok, val}ou{:error, reason}pour ce qui est prévisible etraise/rescuepour ce qui ne l'est pas.Dans certains cas je peux considérer qu'une requête HTTP qui retourne une 404 est prévisible mais qu'un network unreachable ne l'est pas : est-ce que la ressource existe ?
Dans d'autres cas, je considère que toute erreur est imprévisible : j'ai besoin de tel document
Dans le premier cas, si je reçois un
{:error, 404}je peux retournerfalseet laisser l'exception network unreachable se propager.Dans le second cas je transforme le
{:error, reason}en exception (unwrap).Les Result et les exceptions permettent tout deux de séparer le code et la gestion d'erreur, mais la sémantique, les performances, et l'intégration au système de type sont radicalement différent.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg