It actually is if you known how to read it. It’s extremely verbose, but you can follow any exception down to the exact line of code (or JNI call, I guess) where the problem occurs. I’ll gladly take the kilobytes
Unfortunately, Java programmers seem to hate actually handing errors, so you see a lot of try{} catch (Exception e) { throw System.println("something went wrong");} ruining your life, but that’s not the language’s fault.
OnErrorResumeNext never before have more terrible words been spoken.
Every time I’m reading a PowerShell script at work and see -ErrorAction SilentlyContinue I want to scream into a pillow and forcefully revert their commit.
I’ve actually done it a few times, but I want to do it every time.
I don’t know any programming language where that isn’t the case, though. Unless you’re writing another SerenityOS, you’ll probably use external frameworks and libraries to take care of all the uninteresting stuff.
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.
When reproducing a bug? Most of the time. Reasoning back from the variable name and location of a null dereference with a provided call path is much more than you get with tons of languages, especially when calls from frameworks or external libraries enter the mix.
It won’t tell you exactly what to fix, you’ll need to debug for that (C# does some black magic to allow you to do that, Java doesn’t come close to the capabilities of full fat Visual Studio), but you won’t need to waste any time deciphering where the program crashed.
Every crash is frustrating, but the stack traces themselves are super useful.
It actually is if you known how to read it. It’s extremely verbose, but you can follow any exception down to the exact line of code (or JNI call, I guess) where the problem occurs. I’ll gladly take the kilobytes
Unfortunately, Java programmers seem to hate actually handing errors, so you see a lot of
try{} catch (Exception e) { throw System.println("something went wrong");}ruining your life, but that’s not the language’s fault.Super-advanced java devs like me do it like
try{} catch (Exception e) { System.out.println("something went wrong"); e.printStackTrace(); }And then swallow the error, continue executing the code, and make others wonder why the program printed 40 stack traces but crashed without one.
On Error Resume Nextnever before have more terrible words been spoken.Every time I’m reading a PowerShell script at work and see
-ErrorAction SilentlyContinueI want to scream into a pillow and forcefully revert their commit.I’ve actually done it a few times, but I want to do it every time.
And that’s why you’re a hero.
Yeah cos everyone knows other languages are impossible to write bad code with
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!
Is it possible to make intelliJ do this?
I thought it highlighted the line number in blue when it was your code. I use eclipse so can’t properly remember
I don’t know any programming language where that isn’t the case, though. Unless you’re writing another SerenityOS, you’ll probably use external frameworks and libraries to take care of all the uninteresting stuff.
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.
When reproducing a bug? Most of the time. Reasoning back from the variable name and location of a null dereference with a provided call path is much more than you get with tons of languages, especially when calls from frameworks or external libraries enter the mix.
It won’t tell you exactly what to fix, you’ll need to debug for that (C# does some black magic to allow you to do that, Java doesn’t come close to the capabilities of full fat Visual Studio), but you won’t need to waste any time deciphering where the program crashed.
Every crash is frustrating, but the stack traces themselves are super useful.