By the way, CORS was solved using Moesif Origin & CORS Changer.
== does automatic type conversion and compare the “value”. So a string
"1" equals to an integer
=== does not do type conversion. So when comparing a string to an integer,
false regardless of the value.
It is worth noting that the result of
NaN === NaN is always
isNaN() in such case.
The complete behavior of these two “equal-to” operations is given by the equality tables below, use this cheat sheet when something counter-intuitive happens:
undefinedis a special init value assigned to a variable (implicitly) by the runtime;
nullis a value assigned by a programmer to mark the variable as “I am done with the it”; and
NaNis set to indicate that something goes wrong (again, by the runtime).
- look at the “declaration” portion of your code when encountering
undefined, the uninitialized;
- search for
= nulland evaluate the occurrences in your project when encountering
null, the released; and
- look inside a function implementation and check if the arguments are passed correctly when encountering
NaN, an error.
I think subdividing of these exceptional “nil”s can narrow down the code review scope for bug analysis. Do you think so too? Let me know in the comment bellow.
It is worth noting that
n/0 does not make a
NaN, as some claims. The result should be
undefined) that are not common in other languages.
Following are the examples:
As demonstrated by the code, whenever a variable is not explicitly assigned with a value, which could be the case of an out-of-range array accessing or an ignored function argument, the variable is set as
undefined by the runtime.