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:

1. Super specific stuff that applies only to you.

2. The key words that describe the generic situation you are in

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

Error: tree8d has no root expression. ids: [null,"explfu6",null,"explfu8",null,null,null,null,null,null,null,"explfug",null,null,null,"explfuk",null,null,null,"explfuo"]
    at ExpressionTree.root (/Users/erik/projects/editable-software/render-expression/node_modules/an-expression/an-expression.js:450:15)
    at javascriptToEzjs (/Users/erik/projects/editable-software/render-expression/node_modules/javascript-to-ezjs/js-to-ezjs.js:372:58)
    at /Users/erik/projects/editable-software/render-expression/demo.js:44:18
    at /Users/erik/projects/editable-software/render-expression/node_modules/web-host/web-host.js:71:15
    at Array.forEach (native)
    at /Users/erik/projects/editable-software/render-expression/node_modules/web-host/web-host.js:68:26
    at wrap (/Users/erik/projects/editable-software/render-expression/node_modules/web-host/node_modules/web-site/web-site.js:185:9)
    at Layer.handle [as handle_request] (/Users/erik/projects/editable-software/render-expression/node_modules/web-host/node_modules/web-site/node_modules/express/lib/router/layer.js:95:5)
    at next (/Users/erik/projects/editable-software/render-expression/node_modules/web-host/node_modules/web-site/node_modules/express/lib/router/route.js:137:13)
    at Route.dispatch (/Users/erik/projects/editable-software/render-expression/node_modules/web-host/node_modules/web-site/node_modules/express/lib/router/route.js:112:3)
    at Layer.handle [as handle_request] (/Users/erik/projects/editable-software/render-expression/node_modules/web-host/node_modules/web-site/node_modules/express/lib/router/layer.js:95:5)
    ... this goes on forever

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?

If not, what's happening in javascriptToEzjs? Thats in js-to-ezjs.js on line 372.

Just keep working down the list. Those libraries (ExpressionTree and javascriptToEzjs) are things my code (demo.js) is using, so those are things I want to understand. But once I get further down into web-host.js... that's outside my project. You might start seeing Rails errors or Java errors.

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.

You hope.

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!