How to read an error message
One of the dark arts of programming is learning how to decipher the mysterious messages the computer spits out at you.
When you're just starting out, error messages looks like gibberish. But an experienced programmer can read them like tea leaves. When you're a beginner, you are literally reading a language you've never seen before.
But there are a few general strategies that can keep you moving. Let's look at a few error messages and break them down.
1. Find the Key Words
One of the best ways to deal with an error message is to search for it on Google. If it's short enough, you can cut and paste the whole thing. Sometimes that works, but sometimes it doesn't. It depends how much gobbledygook is in there.
If you can't copy and paste the whole thing, you want to try searching for a smaller piece of your error message. Here's an example:
----jGRASP exec: javac -g Program3.java Program3.java:26: error: incompatible types productNum = input.nextInt(); ^ required: int found: int 1 error ----jGRASP wedge2: exit code for process is 1. ----jGRASP: operation complete.
What we want to do is divide this message into three parts:
Super specific stuff that applies only to you.
The key words that describe the generic situation you are in
Super generic words that the computer spits out all the time
Phrases like "operation complete" are very common. You'll learn over time what these common phrases are, but they're too vague to help narrow your search. Also that "----jGRASP" you see over and over on every line is probably not giving you information, since it's on every line!
Things like paths to specific files are usually too specific to be helpful. In the error above, you seee the words "Program3.java:26"... that :26 means "line 26 in the file Program3.java". Someone else might be having the same problem as you, but maybe on a different line in a file with a different name, so let's leave that out.
The phrases that jump out to me are "error: incompatible types" and "required: int found: int". Try putting those in quotes on Google and you get a bunch of hits.
2. Look for breadcrumbs
Once you've found some people online with a similar problem to you, that doesn't necessarily mean they'll have an answer! But those posts are still incredibly valuable.
The most important thing those posts can do is teach you new words to describe your problem. You can add those words to your query, or find something entirely new to search for. You're not looking for an immediate solution, you're looking for tidbits of information that will lead you through a series of searches to your answer.
3. Trace a line back to the problem
Often your program will spit out a big messy thing called a stack trace.
These can be overwhelming, and if you paste the whole thing into Google you're liable to get nothing:
The first thing you want to do is orient yourself. The "stack" is just a list of all of the different pieces of code you are in, kind of like Russian nesting dolls:
Code inside code inside code inside code
When you look at the stack, you mostly only care about two things. The functions you are in (on the left) and the files those functions live in (on the right). Here's how the above stack trace looks in my brain:
From there, you want to start at the top and work your way down. What's happening at ExpressionTree.root? We know it's in an-expression.js on line 450. Is there something wrong there?
Once you get down into other peoples code, you may need to stop and try another strategy. You can control the code that's above your code in the stack trace but the stuff that's below your code is probably working OK.
4. Clear out sample code
One final tip, which came up when I was trying to debug a CodeMentee's problem today. If you see something that looks like dummy text, like "YOUR_KEY_HERE" or "example-route/:someId" you might have found your problem:
Load paths: /path/to/files Sass::Globbing::Importer on line 33 of /path/to/file from line 33 of /path/to/file Use --trace for backtrace.
In this case /path/to/files isn't a real path. That's just a dummy path that got left in some sample code that the user copied or generated.
Keep asking questions
Understanding errors takes time. The answers don't always come quickly, so you need to put your creativity hat on and keep asking questions.
What do you know? What don't you know? Keep asking yourself these questions and you'll find your way. And don't be afraid to ask for help!