Crash Chasing: Whatever you’re doing stop that. Use the Debugger and Get the Stack Trace.
So one day we were making some software, and then the program is crashing and we don’t know why.
On this day, every single person had many ideas on how to troubleshoot the crash. I remember like 20 different suggestions at least.
All of these suggestions were good suggestions, and each suggestion, if performed, would have narrowed down the search for the cause, via process of elimination.
They were all like: “Try this, to see if it’s this. If no effect, then it is not this.”
Okay, so do a test, if test fails, it is not this cause.
It’s like we were going to one by one, test every possible cause, and then go, “nope, not this thing, next” and then test the next possible cause, and so on ad infinitum.
This is what I call “Trial and Error” a system of elimination. Fine. This is okay, this is fine, this works like all the time for a lot of problems, but a stack trace though, a stack trace is an actual map of what happened, no guessing involved, you just have to read.
You see, I don’t want to guess and then test my hypothesis, I want to KNOW. I want to know exactly why, and exactly where the crash happened. Let the Debugger show you, save you a lot of time, and a lot of guessing. Stack trace is your friend.
Use a Debugger. When it crashes, get the stack trace. Know exactly what line of code the failure happened on, what the exception type is, lots of delicious info to nom nom nom. No guessing.
With a debugger, I can load the Debug symbols of all the third party libraries I am using and step into their code too. No more black box!
Using a debugger saves me a lot of time. Consistently. It is worth the time to get the Debug build of all the libraries I have, or to use take the time to compile my source in Debug mode, because the Debugger shows me exactly where the problem is every time.
Related, My tutorials on Crash Chasing: