let’s not act like Java’s error log is useful
Super-advanced java devs like me do it like try{} catch (Exception e) { System.out.println("something went wrong"); e.printStackTrace(); }
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
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!
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.
I think it’s pretty useful, be interested to hear your hangups with it though because it’s definitely not perfect.
If something goes wrong and I have a stack trace, that plus the type of exception will almost always be enough for me to figure out what’s wrong at least as a starting point. I’ve worked mostly with JVM languages in my career though so maybe I just don’t know how bad it actually is.
The same applies to using the core dump.
In fact, the Python one is the lest useful of the trio.
The developer must either provide the logging and attach a debugger or go get fucked when a runtime error happens
That’s not true though. You can get the backtrace and other useful information from the coredump mentioned by the error message by loading it with gdb. Not as good as attaching it to a living process, since you can’t see step-by-step what happens leading up to the error, but still quite useful.
You can also debug post-mortem with the minidump or the core dump file with WDT on Windows. Great fun and a good way to brush up on your assembly skills
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 read this should never happen
I know this is supposed to be humorous, but there’s a reason why these languages can, and are doing what they’re doing.
Core dumps are also worth learning about, they’re really helpful if you understand them.
gdb: Am I a joke to you?
Yes. It’s a surprisingly bad debugger the more you think about it. I use it largely in assembly and it loves to spit out random errors about memory it tried to access based on the current register state. The shortcuts are kind of dumb.
It certainly works but I wouldn’t call it a pleasure to use.
Ex: try disp x/1i $eip often just doesn’t work.
