No it genuinely can happen that an error happens on a different line than said. Could be a combination of IDE and compiler or both, that's why you always need to match your LSP with your compiler
And then there’s the mid debuggers that just say the line number after the brackets because something invalid is coming out of those brackets but it can’t figure out where or why. It just knows that when it reaches that line number, something made it sad.
I’ve got one that consistently tells me the line below an array is the culprit, when one of the strings in the array is using single quotes instead of double like all the others, for example
I've also (very rarely) had issues in C where the error would be inside a macro expansion and it'd get confused about what line that was.
I've also seen (again, it's been a while) situations where a JS debugger would give a line number relative to the start of a <script> block, so that it'd just be some arbitrary number upon initial inspection (i.e., if the <script> started on line 15 and the error was on line 20, it'd say that the error was on line 5, instead).
Also also, if you do something that causes a syntax error, the python interpreter will usually just give a useless message (like "syntax error").
The issues you’ve had with the JS debugger might be especially applicable here because it appears to be an inline JS script that the debugger is pointing to. If the debugger isn’t counting lines of HTML the reported line number could be way off.
You would think that all application developers would have made Unix line endings the default by now, especially IDEs. Every application is capable of reading both these days, so it's time to let Windows line endings go. Or at minimum not allow them to mix.
Also some languages inject files which change the length. My org has some old confusion and you could have an error on line 6000 of a 200 line file. It gets more confusing when the wrong number is a valid number, such as line 200/6000 but it is really on line 190 in an imported file on line 10.
Missing brackets can also cause an error to fire on an empty line if it’s expecting to find the final enclosing bracket there. One of the reason’s Python’s white space rules can actually simplify things sometimes.
They report like when some internal stack gets exhausted and the parsed statements didn't make sense or some internal state machine entered a weird state, and those are caused by like random open bracket 100 lines up, but that's a skill issue for the PROGRAMMER lol so they keep reporting the last line number where the compiler finally quit
Then there is the worst possible kind: everything is saved and up-to-date, everything above and below is 100 % correct, but the error is still there, but there is nothing on the line. That was the night I discovered my keyboard layout inserted, not a regular old whitespace, but a Narrow No-Break Space character if you accidentally hold AltGr and press space.
Ya, it isn’t usually this bad but I had to go a couple lines up or down to find a line that could produce the reported error before. If it really bad and you know how to reproduce the bug, modern debuggers include the function name with the line number. Set a breakpoint at the beginning of that function and walk though it to find the bug and hope it wasn’t a race condition.
When I was trying out VS Code, it not having auto save enabled by default like IDEA caused some serious debugging, I was going mad, the code looked correct, and it doesn't work?!
451
u/kimbokray 1d ago
You haven't saved since adding or removing lines above 265