It’s always a semicolon or parentheses.
My first suspect is an incorrectly-terminated statement which looks like it should end on line 41. The compiler/interpreter probably read the newline and ticked over before uncovering the error, and didn’t recover properly due to some edge case.
When your #includes get flattened before compiling: “Error on line 1103” (file is 190 lines long)
Sounds like my time compiling autoit code. Fuck I hated that
This is why we have debug and release builds.
So that when actual clients tell us there’s an error on line 42 we close the bug instantly as a no repro.
/s
This happens all the time with TypeScript. The transpiled JS that actually runs will naturally have different line numbers than the TS you wrote!
To be fair, the reported line number is usually close enough that I can find the issue without much trouble.
It’s not my favorite back end language, but it’s what everyone on my team knows…
This is what source maps are for. With the right tools you can debug the original source instead of the minified version.
Remember to add --enable-source-maps and as long as your tools are configured properly it should point to the right line!
Thanks for the tip! I’ll double check that when I get back to work next week.
I’ve written a lot of NodeJS apps in vanilla JS, and plenty of .NET backend stuff too. The transition to serious TS has been relatively recent. I like it alright, but dislike the added complexity that comes with all the various config files - vanilla JS has enough of that already!
Well sure. But the error messages don’t point to those, which was what had me chuckling about this meme.
They would point to the right lines if source maps were included in the build.
Oh, they are included in the build. But I still get error messages that don’t actually point to the line in the TS source file sometimes.
Maybe I have something configured wrong - TS projects always include a more config files of different kinds than I see in other languages I work in - but it happens.
Wait you said back end…
It’s surprisingly good as a backend language, if you don’t really need OOP all that much. The perfect case is probably using it in microservices that only really need to do a bit of data manipulation and some database interfacing.
I’ve had pretty good experiences with it even situations with moderate data manipulation. There are some tricks you can use to engage different phases of the event loop to keep the data processing from blocking too much.
It’s still not as good as Java/C#/Go, of course, but it can help get some more performance out of Node.
You are familiar with NodeJS, yes? 👍
It’s a really popular choice and has been for the few years.
Plot twist: The code is written in Whitespace
I hate whitespace so fucking much. Why must i deal with yaml so much
FFS….
That happens all the time with Python. It often shows me errors in the imported modules, which are easily confused with my own code if I’m tired and don’t read the message properly.
It can also happen in Python if you edit the file after runtime. It parses the code on import, but re-reads the file as text during the error message, so if you added or deleted lines, the error report can report a dubious line.
how’s that the same thing as in the picture?
Here it is in greentext form:
>"error on line 42" >look inside >no code on line 42 mfw python throws errors about other peoples codePython stack traces give you all files involved in the error, with their lines. I don’t know what you’re talking about
hence the
which are easily confused with my own code if I’m tired and don’t read the message properly.
it happens all the time in bash. i write some and there’s no error but everyone complains that i didn’t use brainfuck
You dont like brainfuck!?😨
Depending on the language, this could be an issue where the line above is actually transpiled to be a line below due to inlining in some lambda function or similar.
JS minification can make debugging much harder.
Source maps are friends.
In the early 2010s there was a trend to throw in obfuscation into the minis.
in bash if it happens, it often means i have something wrong in most recent closed loop, which may or may not have closed prorperly, somethign similar with python.
Curse you optimiser!
Only a good stack trace can save you now.
