Check for null | SoloLearn: Learn to code for FREE!

+6

Check for null

In one online tutorial, authors recommend checking for null to do this: let obj; if (typeof obj !== "undefined" && obj !== null) { ... } I think that is also possible: let obj; if (obj != null) { ... } Am I wrong?

6/23/2019 4:20:09 PM

rudolph flash

25 Answers

New Answer

+6

JS Coder This is a good discussion. I can relate to Schindlabua in that, sometime between 2012 and 2014, I might have replaced the practice using: typeof obj === "undefined" with: obj === undefined However, I typically reserve checking for undefined if I'm working with variables that weren't initialized with default values, which has been rare for me since ES6 has been heavily adopted by all modern browsers. In recent years, ES6 features, Babel, JS Lint, TypeScript, JS module pattern usage, feature rich JS IDEs, libraries like ReactJS, unit tests, code reviews, and other tools / practices have made it easier and safer to use checks as simple as: if(obj) {...} However, this would not work well on legacy JS code or any code that pollutes the global scope.

+6

Schindlabua Maybe I should change my name to Gandalf. 😂🤣 JS Coder I take it back about you reminding me of my younger self. You are much more impressive than I ever was at 15. 😉

+5

Well if it isn't null, then it could still be undefined. In JavaScript, null and undefined are not the same thing, how most languages are. In JavaScript, undefined is the default value for any variable not initialized, including parameters not passed to functions. Null is different because it still represents something that is "empty", but it must be explicitly assigned to a variable. Undefined could also be assigned to a variable, but I think it is better practice to use null when you're setting it. Note that typeof will return "undefined" for variables that haven't been created at all. Just checking not null could throw an error if the variable had never been created. To directly answer your question: you are kind of wrong. The version you posted will be fine if you can guarantee that it will be defined and have a value that is not undefined. If you do not know this, it is a safer option to use the first version.

+5

JS Coder That's because the `undefined` in the function scope is, well... as you pointed out, in a separate scope. 😉 Therefore, this function scope instance is different from the instance in the global scope, a.k.a. `window.undefined`. You can test this with the following line: console.log(window.undefined === undefined) This will output true in global and false in the function after the line: `var undefined = 5`.

+4

Yes you are right, the only two values that are double-equals to null are null and undefined. However your version is more confusing for sure, if you just have a quick over the code look it's not clear what you are doing or if you have missed something. I think if you want to check for exactly those two values you should be explicit about it, I prefer `if(x !== undefined && x !== null)`.

+4

Schindlabua It does check undefined with the abstract equals, but typeof prevents errors. If the variable had never been declared before, then typeof would return undefined, while checking strict equality to undefined would error. If you were using something that you would want an error for validation, this would be good, but there are also cases where you would not want an error. Also in most cases abstract equals is bad practice (and if you used a linter it would error by default), so whether doing typeof or not, it would be better to do it with 2 separate expressions with &&.

+4

JS Coder Of course, if I do this: if (obj != null) { ... } I get an error, because the variable is not defined... I also agree with Schindlabua, because when I catch such a error when writing a code, I can fix it at that same stage. This method always makes me define all the variables (if I forget) 😉 By the way. But the desire to write code is not only beautiful ☺, but also effective. That was the question

+4

JS Coder Righteous, righteous 😎🤘! It's awesome to see new professional developers joining the community to share their knowledge with the new generation of programmers. 🙏

+3

I am not a JavaScript programmer. So I googled it. https://www.google.nl/amp/s/www.ajaymatharu.com/javascript-difference-between-undefined-and-null/amp/ It seems to me that in JavaScript. "Undefined" is the real null (according to me as c# programmer) And null is a value that a programmer can use to initialize objects. Please correct me if I am wrong Do Google null vs undefined, you will be suprised.

+3

JS Coder The only possible settings I can imagine where you don't know whether a variable has been declared are: - after using `eval` - inside a `with` block Usage of `with` is no longer recommended and usage of `eval` is extremely rare, checking for the existence of a variable afterwards is even rarer. In all other cases I know that the variable has been declared because I have just written it's name into that if statement. (And if I made a typo I want an error to be thrown) I think the `typeof` check solves a problem nobody is really having. Of course in the extremest of edge-cases you might need it, you are right. But you should use it then and only then. (It certainly hasn't happened to me even once in 10+ years.)

+3

Schindlabua Well one example I've had is with templating languages (specifically ejs). It scopes it all like the with statement except it's not bad practice. When you pass the data object, if it's missing a property, it will error. This could be important for user provided data. These are edge cases like you mentioned, and a linter will probably solve most of them, but to me it seems safer to use typeof.

+3

David Carroll I forgot about the case for checking global scope. I usually use if (x) as well, but sometimes I have to modify it if it could be 0, '', or other falsy values. For anything off sololearn, I always use typescript, so checking anything for undefined usually isn't an issue.

+3

David Carroll Yep, `if(obj)` is clearly superior if applicable :P

+3

JS Coder I must be mixing my conversations up with other people. Either way... glad to have you in the community. I've enjoyed your focus on understanding code beyond the surface. You remind me of a younger me. Oh man... I really hope you're younger than me. 😂🤣

+3

Seriously, looks like you have done a lot more than just your homework. Rock on, JS Coder!

+2

yes it is possible to do it this way

+2

Hah, fair. I'm not sure I like what ejs is doing there but I guess it is a usecase!

+2

David Carroll I'm not a professional, but I feel pretty comfortable with js.

+2

David Carroll I'm 15, so probably. I've had an interest in computers for a few years and have mainly done web/js until I found nodejs.

+2

Schindlabua That means he's at least 150...