Best laugh of the day so far.
Laughed too loud, scared the wildlife outside.
PS, just gotta look at lines above. Maybe rainbow delimiters can help.
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 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!
I’m a former .NET dev … I stopped quite a few years ago after I joined a Bay Area company. It was quite a change. React 1 was just coming out and I used to just write bad JS on my webpages and I had to rewrite our front-end in React. Also, ES5 or 6 or whatever was getting popular and we had to transition from CoffeeScript.
The JS world gave me whiplash after doing so many years of Enterprise .NET. The .NET tools felt so much more polished.
The fundamentals of Node to me were different than .NET. .NET felt like it had a lot more cruft and “magic” at first. With Node it felt deceptively simpler at first. Then when the
requiresyntax was going away and we hadimportsbut then it wasn’t a realimport. It was a TypeScriptimportor awebpackimport that did arequirebehind the scenes. Then I had to understand why we usedtypescriptbut then what was the point oftscvsbabelvswebpackvsesbuildwhat their roles were and I kind got a bit obsessed with understanding what they did and what was happening under the hood. Then Node officially did doimportand I had to understand what that was all about and how it affected our compilers or bundlers.Sorry I rant pointlessly. Godspeed on your journey!
No worries on the ranting!
In this industry where we are all a little afraid to admit that we don’t know something, it’s nice to be reminded that everyone is always learning all the time and that there’s no way any of us can know everything.
I’m enjoying the learning process, despite its paper cuts, and love where I work. I enjoy TS itself but I do wish the process of setting up a new project/config stuff were more streamlined. Maybe in the future!
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.
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
Plot twist: The code is written in Whitespace
FFS….
I hate whitespace so fucking much. Why must i deal with yaml so much
All those closing brackets and commas in json suck too. And XML is a fucking waste of time. I’ll take writing yaml any day.
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!?😨
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.
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.
Curse you optimiser!
Only a good stack trace can save you now.
