purple "null" in log--- What's it mean?

So I go to log a value like this: log("This value is "+object.value) and instead of it coming up "This value is undefined", which I'm used to seeing, the spot just shows the single purple colored word "null".  How is this different? Why is the string portion of the log not displayed?

Good question.  In the general sense, null is a special value like NaN .  I think of it as "this space intentionally left blank".  Where undefined is the just as it says, something that hasn't been defined (or something set to an undefined state).  It has no value because nothing has been assigned to it or someone wants a variable not to exist anymore. In pretty much all cases for javascript I can think of, there is no reason to ever use the null value, save for when you want to distinguish "hasn't been defined" from "intentionally not defined", which rarely comes up. In this specific case, we'd need to know more about where that object came from to know why the value property has been intentionally set to null.

Aha, that makes sense.  Might the value property have been set to null if an operator had made it an impossible value, like putting a 0 in a denominator? Basically is it a built in way to prevent some infinite value from messing things up? I'm thinking I've messed up some math somewhere.

It's unlikely that any mathematical operation results in null. &nbsp;Honestly, I can't think of anything that results in null. (Brian will likely pop on here and give an obscure reference to something! =D &nbsp;Bring it, Brian!). Javascript has a special value for Infinity: &gt; 56/0 Infinity And one for negative infinity, too: &gt; -56/0 -Infinity In the case where something ends up not being a number, it has NaN: &gt; 5*{} NaN This video actually does a great job of pointing out some of the eccentricities of Javascript (and it's really funny!):&nbsp; <a href="https://www.destroyallsoftware.com/talks/wat" rel="nofollow">https://www.destroyallsoftware.com/talks/wat</a> if you're getting an object with a property that is null, something in the code is setting it to that. &nbsp;I'd walk backwards through the code until you find where that property is getting set.

Oh man the answer is so dumb I don't even want to tell you. &nbsp;So I apparently wrote one of my logs with an asterisk instead of a plus sign and when trying to diagnose where the property was getting messed up I continued to copy and paste that bad log without realizing it, spreading my confusion. The null was coming from log("This obj.property is "*obj.property)&nbsp; I didn't realize it until I copied the code here, getting ready to post. &nbsp;Oh well, there goes a couple hours of my life! &nbsp;Right when I get to the point of thinking there's some crazy inexplicable problem going on I always find the issue is some simple shit. Thanks again

Oh man, you and me both. =D Weird that you'd get null from that. &nbsp;Must be something in the log() function causing it to get converted. &nbsp;If you do that elsewhere in javascript, you'd just get NaN.

Huh, strange. &nbsp;Funny video BTW

The Aaron said: It's unlikely that any mathematical operation results in null. &nbsp;Honestly, I can't think of anything that results in null. (Brian will likely pop on here and give an obscure reference to something! =D &nbsp;Bring it, Brian!). Can't think of anything off the top of my head that would produce null was the result of some operation. As you said earlier in the thread, the null value in JavaScript is specifically designed as a "this page intentionally left blank" sort of marker. The Aaron said: Weird that you'd get null from that. &nbsp;Must be something in the log() function causing it to get converted. &nbsp;If you do that elsewhere in javascript, you'd just get NaN. Yeah, log does a number of things with its input we're not 100% aware of. At the very least, log(obj) will call JSON.stringify(obj).

Brian said: The Aaron said: Weird that you'd get null from that. &nbsp;Must be something in the log() function causing it to get converted. &nbsp;If you do that elsewhere in javascript, you'd just get NaN. Yeah, log does a number of things with its input we're not 100% aware of. At the very least, log(obj) will call JSON.stringify(obj). Brilliant! &nbsp;I knew you'd point us in the right direction. =D &gt; "This obj.property is "* undefined NaN &gt; JSON.stringify( NaN ); "null" &gt; JSON.stringify("This obj.property is "* undefined ); "null"

Were copious amounts of drugs involved in the design of JS? Its type conversion behaviour seems to be about as predictable as a drunk monkey throwing darts...

hehehe.. did you watch the video up above? The history of the Javascript language is very colorful. =D &nbsp;I think Javascript: The Good Parts by Douglas Crockford talks about it quite a bit. &nbsp;(Which is a great book on Javascript that I recommend to anyone wanting to write good Javascript. =D)

Jakob said: Were copious amounts of drugs involved in the design of JS? Its type conversion behaviour seems to be about as predictable as a drunk monkey throwing darts... This isn't (entirely) the fault of JS in this case. JSON doesn't include NaN, Infinity, -Infinity, or undefined. Of course, the reason &nbsp;JSON doesn't include those things is the fault of JS... because those are not actually JS keywords, they are actually properties of the global object, and their value could potentially be changed. The design philosophy of JSON is such that eval(jsonString) or JSON.parse(jsonString) should always produce the same result, no matter the environment's state. JSON is a subset of ECMAScript which only includes literal values, which means no property lookups. Since these things are properties of the global object, each use is a property lookup. Even executing 1/0 will perform a lookup on the NaN property, and if that property has been redefined... NaN = { valueOf: function() { /* do evil */ } }

The Aaron said: hehehe.. did you watch the video up above? The history of the Javascript language is very colorful. =D &nbsp;I think Javascript: The Good Parts by Douglas Crockford talks about it quite a bit. &nbsp;(Which is a great book on Javascript that I recommend to anyone wanting to write good Javascript. =D) Yes, I did... part of the reason I wrote that comment :D. Overall, they really made it easy to write bad code in Javascript. Which I've slowly been finding out by writing bad code for roll20. @Brian: You can redefine NaN? You can redefine &nbsp;undefined? I'm sure there's so many situations where that is a good idea... .Anyway, in that light, the behaviour of JSOn seems reasonable enough.

Incidentally, Douglas Crockford created the JSON format.&nbsp;