Un meilleur nom pour NaN
, décrivant sa signification plus précisément et avec moins de confusion, serait une exception numérique . C'est en réalité un autre type d'objet d'exception déguisé en type primitif (par la conception du langage), où en même temps il n'est pas traité comme primitif dans sa fausse auto-comparaison. D'où la confusion. Et tant que la langue "ne se fera pas la volonté" de choisir entre un objet d'exception approprié et un chiffre primitif , la confusion restera.
La tristement célèbre non-égalité de NaN
lui-même, à la fois ==
et ===
est une manifestation de la conception déroutante forçant cet objet d'exception à être un type primitif. Cela brise le principe fondamental selon lequel une primitive est uniquement déterminée par sa valeur . Si l' NaN
on préfère être considéré comme une exception (dont il peut y avoir différents types), alors il ne doit pas être «vendu» comme primitif. Et si on veut qu'il soit primitif, ce principe doit tenir. Tant qu'il est cassé, comme nous l'avons dans JavaScript, et que nous ne pouvons pas vraiment décider entre les deux, la confusion menant à une charge cognitive inutile pour toutes les personnes impliquées restera. Ce qui, cependant, est vraiment facile à corriger en faisant simplement le choix entre les deux:
- soit créer
NaN
un objet d'exception spécial contenant les informations utiles sur la façon dont l'exception est survenue, au lieu de jeter ces informations comme ce qui est actuellement implémenté, conduisant à un code plus difficile à déboguer;
- ou créer
NaN
une entité de type primitif number
(qui pourrait être moins confuse appelée "numérique"), auquel cas elle devrait être égale à elle-même et ne peut contenir aucune autre information; ce dernier est clairement un choix inférieur.
Le seul avantage concevable de forcer NaN
dans le number
type est de pouvoir le renvoyer dans n'importe quelle expression numérique. Ce qui, cependant, rend le choix fragile, car le résultat de toute expression numérique contenant NaN
sera soit NaN
, soit conduira à des résultats imprévisibles tels que l' NaN < 0
évaluation false
, c'est- à -dire le retour boolean
au lieu de conserver l'exception.
Et même si «les choses sont telles qu'elles sont», rien ne nous empêche de faire cette distinction claire pour nous-mêmes, pour aider à rendre notre code plus prévisible et plus facile à déboguer. En pratique, cela signifie identifier ces exceptions et les traiter comme des exceptions. Ce qui, malheureusement, signifie plus de code mais, espérons-le, sera atténué par des outils tels que TypeScript de Flowtype.
Et puis nous avons la distinction de signalisationNaN
désordonnée calme vs bruyante aka . Ce qui concerne vraiment la façon dont les exceptions sont gérées, pas les exceptions elles-mêmes, et rien de différent des autres exceptions.
De même, Infinity
et +Infinity
sont des éléments de type numérique apparaissant dans l' extension de la ligne réelle mais ce ne sont pas des nombres réels. Mathématiquement, ils peuvent être représentés par des séquences de nombres réels convergeant vers l'un +
ou l' autre -Infinity
.