It’s a common issue when trying to start up your application. Something goes wrong, there’s a load of trace on the console, and you need to try to work out what could be the problem.
There’s are various cognitive biases that affects our ability to resolve these problems. We often expect the thing we last did to be the cause of the problem. We can theorise wildly about how the machine must be processing our request, and when it goes wrong, start to follow our wild theories, rather than zero in on the actual problem.
Frequently, when I encounter a period of wild guessing, the solution is staring me in the face. What does the error message actually say!?
Now, it’s not necessarily a case of what errors do we have? Often, there are loads of them, and the errors frequently point to the wild theories we’ve been wasting time on. The more important point is What does THE error message say?
There’s usually one very important error message in the output which gives us the clue.
And it’s usually not the most obvious one.
And there are usually more flamboyant ones which grab your attention and distract you from the important one… which may even be a warning.
Breaking out of the Loop
If the wild theories, guesswork and voodoo haven’t worked, then it’s time to take a moment’s pause.
- Look at all the errors in the output
- Try to understand the network of errors – which ones are secondary, where’s the root cause?
- Look at the wording, maybe even look at the code that throws that particular error
- Consider how to test with a different scenario where that error could never occur
- Simplify the set up, so that something simpler goes right, so you can build back up to the full scenario, with more idea of which increment makes it start to go wrong
If you’re working with decent technology, the errors should give you more clues than it first appears they do; they should help you.
Should being the key word here!
Making It Easy On Ourselves
Of course this implies that we need to be more careful with throwing errors, checking inputs and logging things in our apps. If we don’t, then we ONLY have guesswork to fall back on when we’re debugging them.
Published on Java Code Geeks with permission by Ashley Frieze, partner at our JCG program. See the original article here: RTFE – Read The Flaming Error Opinions expressed by Java Code Geeks contributors are their own. |
