Re: Pas sûr que trouver des erreurs/la fiabilité soit si important pour la communauté libre..

Obliger le développeur, c'est le meilleur moins d'obtenir, pardonne moi l'expression, de la merde. Exemple ? Les try/catch foireux en java à cause de l'obligation de gérer les exceptions (i.e., le catch est vide, mais c'est nécessaire pour que cela compile).

Bon exemple, l'obligation du try/catch ça rend la merde de tes développeurs visible.

D'après toi qu'est-ce qui est mieux entre :

int value = (int) anotherValue;

et

int value;
try {
 value = anotherValue.atoi()
} catch(...) {
}

Le second montre clairement que tu as un cas d'erreur possible (que tu le traite ou non), il t'oblige à donner un valeur par défait (si tu utilise value sans l'initialiser dans la plupart des langages ton compilateur va hurler).

Tu ne pourra jamais empêcher un développeur qui fait n'importe quoi à faire n'importe quoi. La preuve de programme n'empêche pas celui qui l'a fait de faire n'importe quoi.

Ce qui est reprochable à des langages comme java c'est de ne pas être suffisamment expressif pour gérer tout ça de manière réellement agréable (entre autre via le patern matching, la capacité à produire du code exception free et la capacité du langage à exprimer tes contraintes dans des types -là dessus ada est pas mal-).

Au passage, ta preuve de programme va simplement t'obliger à écrire ce code de gestion d'erreur, peut être moins car tu exprime mieux les contraintes de tes données (tu sais que ta méthode n'est jamais utilisé qu'avec en entrée des valeurs paires).

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)