Following up on How to Solve a Technical Problem Step 1: Define the Problem the next step is to understand error messages.
Over they many years, we see users completely "blow over" reading error messages. More-often-than-not, the solution to a problem is defined in the error message. However, the major of forum users do not post the exact error message they received. When they do "define the problem" by posting the error message, the key to the solution is generally in the error message.
Let take this very trivial example from Step 1.
Here is the example script:
Example: a.sh
#!/bin/bash
echo "hello world
Here is how we run this code and the error message:
macos$ bash ./a.sh
./a.sh: line 2: unexpected EOF while looking for matching `"'
./a.sh: line 3: syntax error: unexpected end of file
>
As we can clearly see, the error message tells us a double quote is missing and this causes the interpreter to terminate EOF without finding this missing double quote.
Now, a lot of beginners just go straight to a forum and ask "why is my script broken" without actually looking at the error message and paying close attention to it.
This is a part of the "Define the Problem" approach, a continuation of Topic 1.
What do I generally do when I get an error message which I do not understand?
This might surprise you, but I just as you do, and copy-and-paste the generic part of the error message into a browser and search for what exists "in the wild" on this error already.
Of course, in this trivial example, we don't need to "copy-and-paste" into Google, but let's do it anyway. The results are interesting:
In my case, Google returns:
About 183,000 results (0.50 seconds)
and on the first page, our favorite tech forum www.unix.com provides search results (in this case I am posting from Thailand so the dates are in the Thai system, but never mind that, your search results will be different).
When posting to a forum looking for an answer, it is very important to post the exact error message, copy-and-pasted from your screen or console. There is at least three good reasons for this:
- Forum members can see the exact error and so they will understand the problem (and can search if they need to);
- Future internet searches will find the result because they will search on the same error message and find out how others solved this problem in the past or how they dealt with a similar error.
- Documenting the exact error is a key step in defining any problem and error messages are a part of that process.
It might come as a shock to you, but most members who come to a forum to ask a question when they have an error, do NOT post the exact error message they received.
I know, it's crazy; but that's what we have seen in at least two decades at unix.com.
People wish / want / demand solutions to problems and errors but they fail to provide the most basic information, time and time again, as if we are all supernatural beings (wizards) in a tall castle with a huge crystal ball.
Guessing at solutions, offering suggestions without understanding the problem, is just guessing. Personally, I do not like guessing although we do see that some forum experts seem to take pride in guessing a poster's problem and writing code to solve what they guess to be the problem.
I prefer to take most of the guesswork out of problem solving and my experience has shown me that the better any technical computer related problem is defined, the faster and easier the solution materializes.
Later, I will post come hints on how to quickly debug problems without using "fancy" debugging tools.
Cheers.
See Also: