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.
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.