I hate these. You don’t need to program for very long before you see one of these. And, you get used to the idea that when it says there’s an error on a blank line, that it means something isn’t properly terminated on one of the previous lines. But, man, I hate these.
At the very least, you’d hope that by now compilers/interpreters would be able to say “error somewhere between line 260 and 265”. Or, more usefully “Expected a closing ‘)’ before line 265, opening ‘(’ was on line 260”.
Error on <blank line> just pisses me off because the compiler / interpreter should know that that isn’t true. Whoever wrote the compiler is a seasoned developer who has been hit by this kind of error message countless times. They must know how annoying it is, and yet…
My personal favorite is when it complains about a missing semicolon. So it’s 100% knows what the problem is, it knows where the problem is, and it knows how to fix it. But it’s not going to fix it out of spite.
Thing is, if it just guesses what you meant instead of sticking to the standard, you can end up with ambiguous meanings. Like what if you forgot a character that wasn’t a semicolon but inserting a semicolon would turn it into valid code?
Like:
x = y z++;
Inserting a semicolon would turn that into set x to the value of y and then increment z. But maybe the line is missing a plus instead of a semicolon and the intent was to set x to y plus z and then increment z.
It’s a pain but strict syntax helps avoid frustrating to debug bugs.
Taking it a step even further, you can make your code more robust by treating warnings similarly to errors. Even though the general cases usually still work despite warnings, they are great for avoiding edge cases that can also be difficult to debug. At least if you take the time to understand what the warning is really about and don’t just google “how to get rid of warning x” and add some casts or something you don’t understand to make the message go away.
That’s the worst when your cycle time is very long. You fix a bug in the code, start your test running again and come back to check the next day only to see the exact same bug again and might think that your fix didn’t work and something more esoteric is going on (“maybe it’s a compiler or hardware bug!” (It almost never is)).
Then you add a bunch of debug prints to really get a good idea of what’s going on and rerun the test. Either you remembered to save and suddenly the mystery bug is gone because the fix is still in the code. Or maybe you forgot to save again and now it looks like it’s not even reaching any of the code you added the prints to.
I hate these. You don’t need to program for very long before you see one of these. And, you get used to the idea that when it says there’s an error on a blank line, that it means something isn’t properly terminated on one of the previous lines. But, man, I hate these.
At the very least, you’d hope that by now compilers/interpreters would be able to say “error somewhere between line 260 and 265”. Or, more usefully “Expected a closing ‘)’ before line 265, opening ‘(’ was on line 260”.
Error on <blank line> just pisses me off because the compiler / interpreter should know that that isn’t true. Whoever wrote the compiler is a seasoned developer who has been hit by this kind of error message countless times. They must know how annoying it is, and yet…
My personal favorite is when it complains about a missing semicolon. So it’s 100% knows what the problem is, it knows where the problem is, and it knows how to fix it. But it’s not going to fix it out of spite.
Thing is, if it just guesses what you meant instead of sticking to the standard, you can end up with ambiguous meanings. Like what if you forgot a character that wasn’t a semicolon but inserting a semicolon would turn it into valid code?
Like:
x = y z++;
Inserting a semicolon would turn that into set x to the value of y and then increment z. But maybe the line is missing a plus instead of a semicolon and the intent was to set x to y plus z and then increment z.
It’s a pain but strict syntax helps avoid frustrating to debug bugs.
Taking it a step even further, you can make your code more robust by treating warnings similarly to errors. Even though the general cases usually still work despite warnings, they are great for avoiding edge cases that can also be difficult to debug. At least if you take the time to understand what the warning is really about and don’t just google “how to get rid of warning x” and add some casts or something you don’t understand to make the message go away.
Oh boy, are you gonna LOVE Javascript
Is your point that JS doesn’t really need semicolons at all any more?
Not just that, it’s the reason why it doesn’t need semicolons: https://en.wikibooks.org/wiki/JavaScript/Automatic_semicolon_insertion
Javascript and html are more suggestions on how to write something that may work in a web browser.
This is why i flunked college
There’s also “you forgot to save before you ran the compiler”, and yeah, whatever is on that line in the stored to disk version is garbage.
That’s the worst when your cycle time is very long. You fix a bug in the code, start your test running again and come back to check the next day only to see the exact same bug again and might think that your fix didn’t work and something more esoteric is going on (“maybe it’s a compiler or hardware bug!” (It almost never is)).
Then you add a bunch of debug prints to really get a good idea of what’s going on and rerun the test. Either you remembered to save and suddenly the mystery bug is gone because the fix is still in the code. Or maybe you forgot to save again and now it looks like it’s not even reaching any of the code you added the prints to.
May I introduce you to our Lord and savior, rustc?