Hum, ce que tu propose ressemble fortement à Java qui indique(indiquait?) dans le prototype des fonctions les exceptions potentiellement levée ce qui causé pas mal de protestations car c'est pénible à gérer..
Il y a plusieurs choses à voir.
D'une part il n'y a qu'une partie des exceptions qui doivent être gérées (soit en étant attrapées soit en étant déclarée plus haut). Les Error et les RuntimeException ne sont pas obligatoirement gérées (en fait d'un point de vu pratique c'est des choses qui peuvent arriver n'importe quand. Ce sont les CheckedException qui doivent être gérées.
Pour ce qui est des problèmes de contamination que ça entraine. De mon point de vu une méthode cliente doit gérer l'exception (ou l'encapsuler) et je ne pense que que c'est un problème que la méthode cliente ai un couplage fort avec la classe appelée.
D'autre part même si c'est plus verbeux, je ne trouve pas ça plus contraignant que le pattern matching qu'on trouve avec l'inférence de type.
les scopes (*) qui remplacent en mieux le try .. finally
Si j'ai bien compris. Dans un bloc d'instruction on place une instruction du type :
scope(failure)foo(m);
et si on sort de ce bloc en erreur (pour le cas en exemple), la méthode foo est appelée. Par contre la documentation semble dire que la détection des erreurs se fait encore via des exceptions (ou alors je n'ai pas compris « scope(failure) executes NonEmptyOrScopeBlockStatement when the scope exits due to exception unwinding. »). Donc ça ne remplace pas vraiment les exceptions.
Je ne vois pas non plus comment tu peut gérer certains cas avec. Pour libérer des ressources c'est super (les exemples le montre), mais quand il s'agit de gérer une erreur par exemple pour écrire dans un log ou remonter une information à l'utilisateur, tu es obligé d'utiliser une variable globale qui va contenir l'information alors dans quand les cas « classiques » (qu'on trouve en Java ou C++ par exemple) c'est l'exception qui contient cette information. Ça me semble plus propre.
les références non-nullable par défaut et le type Maybe.
Les valeurs null sont une plaie. D'ailleurs on vois en Java avec common lang, guava ou la dernière version de Java SE qu'une partie des aides sont en faites des helpers pour gérer les valeurs null. J'aime bien l'approche patern matching qu'on trouve dans les langages fonctionnels pour ça (on est obligé de gérer la valeur null (ou plutôt le type null quand celui-ci peut se présenter)). Les types nullables de C# sont plutôt pas mal je trouve, ils obligent les développeurs à gérer les cas de valeurs null.
la gestion d'exception "à la Lisp" qui semble un peu différente des autres, mais je ne comprends pas bien si c'est vraiment un avantage en pratique..
Tu parle du fait de pouvoir corriger et rejouer la partie incriminées ? J'ai encore jamais utilisé un tel système, je ne peux pas en dire beaucoup plus que toi.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: dommage
Posté par barmic . En réponse au journal The Future of Functional Programming Languages. Évalué à 2.
Il y a plusieurs choses à voir.
D'une part il n'y a qu'une partie des exceptions qui doivent être gérées (soit en étant attrapées soit en étant déclarée plus haut). Les Error et les RuntimeException ne sont pas obligatoirement gérées (en fait d'un point de vu pratique c'est des choses qui peuvent arriver n'importe quand. Ce sont les CheckedException qui doivent être gérées.
Pour ce qui est des problèmes de contamination que ça entraine. De mon point de vu une méthode cliente doit gérer l'exception (ou l'encapsuler) et je ne pense que que c'est un problème que la méthode cliente ai un couplage fort avec la classe appelée.
D'autre part même si c'est plus verbeux, je ne trouve pas ça plus contraignant que le pattern matching qu'on trouve avec l'inférence de type.
Si j'ai bien compris. Dans un bloc d'instruction on place une instruction du type :
et si on sort de ce bloc en erreur (pour le cas en exemple), la méthode foo est appelée. Par contre la documentation semble dire que la détection des erreurs se fait encore via des exceptions (ou alors je n'ai pas compris « scope(failure) executes NonEmptyOrScopeBlockStatement when the scope exits due to exception unwinding. »). Donc ça ne remplace pas vraiment les exceptions.
Je ne vois pas non plus comment tu peut gérer certains cas avec. Pour libérer des ressources c'est super (les exemples le montre), mais quand il s'agit de gérer une erreur par exemple pour écrire dans un log ou remonter une information à l'utilisateur, tu es obligé d'utiliser une variable globale qui va contenir l'information alors dans quand les cas « classiques » (qu'on trouve en Java ou C++ par exemple) c'est l'exception qui contient cette information. Ça me semble plus propre.
Les valeurs null sont une plaie. D'ailleurs on vois en Java avec common lang, guava ou la dernière version de Java SE qu'une partie des aides sont en faites des helpers pour gérer les valeurs null. J'aime bien l'approche patern matching qu'on trouve dans les langages fonctionnels pour ça (on est obligé de gérer la valeur null (ou plutôt le type null quand celui-ci peut se présenter)). Les types nullables de C# sont plutôt pas mal je trouve, ils obligent les développeurs à gérer les cas de valeurs null.
Tu parle du fait de pouvoir corriger et rejouer la partie incriminées ? J'ai encore jamais utilisé un tel système, je ne peux pas en dire beaucoup plus que toi.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)