0
if (foo) {
    // code to run if foo exists    
}

results in Uncaught ReferenceError: foo is not defined

So how am i supposed to check if foo exists?

sherlock
  • 744
  • 7
  • 21

1 Answers1

2

There's several ways - one is

if(typeof foo !== 'undefined'){
   // your code here.
 }

JS FIDDLE to play with to check

James
  • 3,233
  • 3
  • 40
  • 57
  • That method may lead to false positives: `var foo = undefined`. – user2246674 Jul 26 '13 at 01:31
  • 1
    I think you've got an extra `=` in there. – Mark Parnell Jul 26 '13 at 01:32
  • I did, fixed and Fiddle added. – James Jul 26 '13 at 01:33
  • @user2246674 not quite. The conditional is based on the _type_ of foo, not the contents. – Chris Thompson Jul 26 '13 at 01:37
  • @ChrisThompson Variables in JavaScript have no type. Try `a = undefined; typeof a === typeof b`. – user2246674 Jul 26 '13 at 01:39
  • dat unnecessary semicolon makes my eyes sweat water uncontrollably – ajax333221 Jul 26 '13 at 02:10
  • @ajax333221 - removed ;) – James Jul 26 '13 at 02:17
  • @user2246674 what is the "false positive" there? – Evan Davis Jul 26 '13 at 02:25
  • @Mathletics The `a` identifier is resolvable. The `b` identifier does not resolve. This incorrectly detected that `a` "didn't exist", and hence a false positive. But `a` *did exist* (it would not have throw a ReferenceError if used) and merely evaluated to `undefined` as previously assigned. – user2246674 Jul 26 '13 at 02:26
  • @user2246674 ok, but is there an actual use case for checking whether a variable has been _declared_ or not? And do you have a superior method to avoid this "false positive"? – Evan Davis Jul 26 '13 at 13:36
  • @Mathletics The only way to guarantee if a *variable* is declared is to use it - and test for a ReferenceException. However, this is a cludge that covers up the core issue; let's imagine these rules: 1) *local variables* must be "in scope" so such code is deemed to be invalid and thus no check is required; 2) this isn't really about variables, but rather *global properties* that have not been assigned; in this case, `window.foo` will safely evaluate to undefined when the property does not exist; 3) Continuing with #2, the way to check if a *property* is missing: `!("foo" in window)`. – user2246674 Jul 26 '13 at 21:39
  • @Mathletics Actually, IIRC, some IE's choked with `in` on windor. The alternative that is equivalent here is `window.hasOwnProperty("foo")`, although it has subtle differences (that don't matter here). Now, if `with` is introduced then the resolution differs .. but that's another issue and identifier resolution can only be correctly detected with handling ReferenceExceptions. In any case, for anything except a *global property* (which I uniformly handle as `window.foo`), I would consider "test for variable existence" to be an inferior/anti-pattern. – user2246674 Jul 26 '13 at 21:47
  • @user2246674 right. Trivia wankery aside, is there a __useful__ difference between `window.foo = undefined` and `window.foo` having never been set? – Evan Davis Jul 27 '13 at 00:36
  • @Mathletics I only put "namespaces" on window so, for me: no. Using the property form allows me to use the `window.foo = window.foo || ..` or `if (!window.foo) { .. }` idioms. – user2246674 Jul 27 '13 at 00:37
  • @user2246674 that is my point. While the key exists on the object in the explicitly undefined case, there is no useful case in which the "false positive" of an explicitly undefined key coming up `undefined` in a `typeof` test. – Evan Davis Jul 27 '13 at 00:43
  • @Mathletics It doesn't matter. My statement was correct about checking for *existence*. I would encourage people to step back and view global properties for what they are - as are distinct entities from local variables - and reflect on what usage patterns provide the most clarity. – user2246674 Jul 27 '13 at 00:48
  • @user2246674 sure, in the [Number 1 Bureaucrat](http://www.youtube.com/watch?v=hou0lU8WMgo) sense, but _existence_ is not a useful qualifier in JavaScript (unless someone can show me a use case, and please do!) Otherwise you're over-intellectualizing a non-issue at the _expense_ of clarity. – Evan Davis Jul 27 '13 at 01:04
  • @Mathletics I hope that someone, someday, will read my comments above and gain *additional* clarity on how JavaScript resolves identifiers. – user2246674 Jul 27 '13 at 01:11