Un mejor nombre para NaN
, describiendo su significado de manera más precisa y menos confusa, sería una excepción numérica . Realmente es otro tipo de objeto de excepción disfrazado de tipo primitivo (por el diseño del lenguaje), donde al mismo tiempo no se trata como primitivo en su falsa auto-comparación. De ahí la confusión. Y mientras el lenguaje "no decida" elegir entre un objeto de excepción apropiado y un número primitivo , la confusión se mantendrá.
La infame no igualdad de NaN
sí mismo, ambos ==
y ===
es una manifestación del diseño confuso que obliga a este objeto de excepción a ser un tipo primitivo. Esto rompe el principio fundamental de que una primitiva está determinada únicamente por su valor . Si NaN
se prefiere ser visto como una excepción (de los cuales puede haber diferentes tipos), entonces no debe "venderse" como primitivo. Y si se quiere ser primitivo, ese principio debe mantenerse. Mientras esté roto, como lo hemos hecho en JavaScript, y realmente no podemos decidir entre los dos, la confusión que conduce a una carga cognitiva innecesaria para todos los involucrados seguirá siendo. Lo cual, sin embargo, es realmente fácil de solucionar simplemente haciendo la elección entre los dos:
- haga
NaN
un objeto de excepción especial que contenga la información útil sobre cómo surgió la excepción, en lugar de desechar esa información como lo que está implementado actualmente, lo que lleva a un código más difícil de depurar;
- o hacer
NaN
una entidad del tipo primitivo number
(que podría llamarse menos confusamente "numérico"), en cuyo caso debería ser igual a sí mismo y no puede contener ninguna otra información; esta última es claramente una elección inferior.
La ventaja sólo es concebible de forzar NaN
al number
tipo es ser capaz de tirar de nuevo en cualquier expresión numérica. Lo que, sin embargo, lo convierte en una opción frágil, porque el resultado de cualquier expresión numérica que contenga NaN
será NaN
, o dará lugar a resultados impredecibles, como NaN < 0
evaluar a false
, es decir, regresar en boolean
lugar de mantener la excepción.
E incluso si "las cosas son como son", nada nos impide hacer esa distinción clara para nosotros mismos, para ayudar a que nuestro código sea más predecible y más fácil de depurar. En la práctica, eso significa identificar esas excepciones y tratarlas como excepciones. Lo cual, desafortunadamente, significa más código, pero con suerte será mitigado por herramientas como TypeScript de Flowtype.
Y luego tenemos la distinción de señalizaciónNaN
desordenada silenciosa vs ruidosa . Lo que realmente se trata de cómo se manejan las excepciones, no las excepciones en sí mismas, y nada diferente de otras excepciones.
Del mismo modo, Infinity
y +Infinity
son elementos de tipo numérico que surgen en la extensión de la línea real pero no son números reales. Matemáticamente, se pueden representar mediante secuencias de números reales que convergen a cualquiera +
o -Infinity
.