ReferenceError

[gfwilliams]

Posted at 2015-08-12 by @gfwilliams

There's been an issue open on GitHub for a while, where 'normal' JavaScript should throw an error if you use a variable without defining it first, but Espruino doesn't:

a=1; // no error
console.log(b); // should throw 'ReferenceError', but Espruino doesn't

Now usually having ReferenceError is great, because it stops loads of mistakes that would otherwise go un-noticed, like:

Serial1.setup(9600, { parity:'odd' }) // Ok
Serial1.setup(9600, { parity:odd }) // Error (variable odd is undefined, so you'd actually get no parity)
foobar = 1;
digitalWrite(LED1, fooBar); // Error (case sensitive, so fooBar->undefined->0)

However I'm very conscious that most of us probably do have some errors that are currently going un-noticed and actually aren't causing any problems... So would you feel fed up if you updated the Espruino firmware and then your program stopped working? At least it would at least tell you where the problem was!

I've just implemented this, but on a branch called ReferenceError. The latest build with it on is now here if you want to check it out: http://www.espruino.com/binaries/git/commits/0858ecfb5e6b1f894ce8648f750098ce4a1950f5

I'd be interested to see what you think?

[espruino-discuss3]

Posted at 2015-08-12 by Rollo

Personally I would be happy to get my code cleaner and fix these nasty mistakes.

I guess after update it would fail badly so it would be easy to fix, otherwise one can spend hours chasing bugs in the wrong place (because they will bite you eventually).

---

Posted at 2015-08-12 by JumJum

I would prefer to have this check, lot of errors on my side would have been found much faster.
Would it be an option to switch ReferenceCheck on or off with something like E.referenceCheck(true/false/undefined) ?
Option undefined could return actual status of this flag.

---

Posted at 2015-08-13 by the1laz

I'd prefer to have the check. I've been stung here before.

With regards to making code-breaking changes to Espruino, I know that good changes to features or functions often clashes with your policy of maximising user friendliness. Could it help to bundle changes like this into single, major, loudly publicised releases so that users are well aware that of what could break and what to do about it if they update?

---

Posted at 2015-08-13 by DrAzzy

I think this check should probably be in, though I share laz's concern about breaking code.

I'm having trouble thinking of cases where someone might be relying on this whilest the code still works, short of really awful things where variables are named dynamically by making strings and evaling them.

---

Posted at 2015-08-13 by the1laz

I'm not too worried about breaking code, I'm actually more worried about not
making changes like this because it might break code.

---

Posted at 2015-08-13 by @gfwilliams

Thanks! Glad it's all positive :)

I guess Serial1.setup(9600,{parity:none}) is a good example - something I've seen posted up here in code, and that works perfectly fine normally.

The most frustrating as far as I'm concerned is a===undefined, which I feel should still work, but doesn't after ReferenceError.

But yes, I've lost count of all the bugs that ReferenceError would have alerted me to - I can't wait to get it in!

I've been in two minds about having switchable features - in a way it'd help, but then it makes the code more complex and harder to maintain... If ReferenceError were on by default then code would still break when someone updated, and if it were off by default then most people won't know to turn it on.

Pushing all the stuff into a big release is an option I guess (I don't have any other major breakages planned though!) - but do you think there's a chance that it could be a bit like Python 2.7 -> 3, where if you do too many changes in one go, people just give up and stay using the old one?

---

Posted at 2015-08-13 by the1laz

It could be like python, same thing happened with angularjs. "Breaking changes" seems to be a very difficult part of building languages/frameworks, and I don't know how best to deal with it. I think it needs to be planned for though, otherwise it gets really hard to justify making improvements. I'll happily try and brainstorm ideas for how to do it...

Switchable features sounds like an extra overhead in terms of your workload and in terms of code size. And an additional confusion for new users. I think for it to work you'd really need to commit to having features be "on" or "off", but have an extremely minimal and "not technically supported, but available for advanced users" way of switching them.

---

Posted at 2015-08-14 by alexanderbrevig

Just wanted to add my +1 for adding ReferenceError :)

---

Posted at 2015-10-03 by the1laz

Just realised with this, typeof needs to be able to work, otherwise you can't check to see if something is defined.

---

Posted at 2015-10-03 by @allObjects

@gfwilliams, in the past, the not defined yet - which is different from defined but having the value undefined - was working... or is it just my imagination?

In the beginning I hated it, but for safe programming, it is better to differentiate between the reference undefined or the referenced value undefined.

I assume that something has changed in the code where a variable reference (and function reference, which is basically the same) is looked up. In the past, as recalling my experience, I would get an error...

---

Posted at 2015-10-05 by @gfwilliams

@the1laz typeof does work? In some earlier builds it didn't, but I fixed it.

In 1v80 you don't get an error if you've not used something before. For instance:

setInterval(function() {
  print(i++);
}, 1000);

Will just print NaN I think? Not good.

I'm pretty confident now that in pretty much all cases (apart from the careful on=!on; example code I used to use) the ReferenceError will actually help to point out code that was in error (like Serial1.setup(...,{parity:even});, so hopefully it won't annoy people too much!

---

Posted at 2015-10-05 by the1laz

Maybe my firmware is a bit old, I'll check.