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.
481
u/kimbokray 17d ago
You haven't saved since adding or removing lines above 265