Joke on you until the python program segfaults
My favorite compile error happened while I was taking a Haskell class.
ghc: panic! (the ‘impossible’ happened)
The issue is plainly stated, and it provides clear next steps to the developer.
I had a similar error, though not from the compiler
Error message just readthis should never happen
Except the C++ “Core dumped” line is telling you it just wrote a file out with the full state of the program at the time of the crash, you can load it up and see where it crashed and then go and look at what every local variable was at the time of the crash.
Pretty sure you can even step backwards in time with a good debugger to find out exactly how you got to the state you’re currently in.
Where does it write the file
Nobody knows
I believe it’s
/var/lib/apport/coredumpon Ubuntu.imagine if it, like, told you this so you didn’t have to find out about it via a post on lemmy
imagine if it like, read that file and gave you a stack trace
gdb gives you waaaaaaaaaaaaaaay more than a stack trace.
Imagine if you knew the most basic foundational features of the language you were using.
Next we’ll teach you about this neat thing called the compiler.
I’m not a C/C++ dev, but isn’t
apportUbuntu’s crash reporter? Why would dumps be going into there?Though on a rhetorical thought, I am aware of systemd’s
coredumptctlso perhaps its collecting dumps the same way systemd does.https://wiki.ubuntu.com/Apport
It intentionally acts as an intercept for such things, so that core dumps can be nicely packaged up and sent to maintainers in a GUI-friendly way so maintainers can get valuable debugging information even from non-tech-savvy users. If you’re running something on the terminal, it won’t be intercepted and the core dump will be put in the working directory of the binary, but if you executed it through the GUI it will.
Assuming, of course, you turn crash interception on- it’s off by default since it might contain sensitive info. Apport itself is always on and running to handle Ubuntu errors, but the crash interception needs enabled.
i mean you’re expected to know the basic functioning of the compiler when you use it
Python: So you used spaces and tabs for indentation? NOW DIE!
Mixing spaces and tabs should be a warcrime.
Find me anyone who claims they use tabs for indentation, and I bet I’ll find at least one case where they’re using both tabs and spaces.
The only safe way to avoid war crimes is to avoid tabs.
I use the tab key but I’m pretty sure vs code converts that to spaces
Good. Spaces and tabs for indentation should never be mixed in any language other than Whitespace.
Some people use tabs for indentation and spaces for alignment. It kind of gets the pros of tabs (user configurable indent-width) and the pros of spaces (alignment). That doesn’t work in Python where you can’t align stuff and the interpreter doesn’t allow mixing tabs with spaces, but in other languages it is a possible style.
There are no pros to tabs. Configure tabs to a number of spaces.
The ole’ single C++ error turning into 600 lines of issues
let’s not act like Java’s error log is useful
deleted by creator
you can follow any exception down to the exact line of code
Which is usually not a piece of code written by us and is caused by another piece of code not written by us either
deleted by creator
Does your IDE not highlight the lines written by you in a different colour? Of course that doesn’t help when it’s an error in production!
Super-advanced java devs like me do it like
try{} catch (Exception e) { System.out.println("something went wrong"); e.printStackTrace(); }deleted by creator
but you can follow any exception down to the exact line of code (or JNI call, I guess) where the problem occurs.
But, it’s not really where the problem occurred. How often do you get a stack trace and the bug fix is at the line referenced by the stack trace? Almost never. It’s more that it takes you down to the exact line of code where the effects of the problem are bad enough to affect the running of the program. But, the actual problem happened earlier, sometimes much earlier.
For example, NullPointerException isn’t actually the problem, it’s a symptom of the problem. Something didn’t get initialized properly, and nobody noticed for a while, until we tried to use it, and got a null pointer. Sometimes it’s easy to go from the effect (null pointer) to the cause (uninitialized thing). But, other times that “thing” was passed in, so you have to work backwards to try to figure out where that thing comes from, and why it’s in that broken state.
Sure, it’s better than nothing, but it’s still frustrating.
deleted by creator
