Here’s How to Better Parse the Results from Googling Your Error MessagesClaire GilliganBlockedUnblockFollowFollowingJan 28Moving to programming from a field in which my job was to be a human resource library (to provide answers to questions people hadn’t yet realized they needed to ask), it was a big shift for me to rely so heavily on Google, as we do.
Especially in the early days, I often wished for a guide to parsing the search results I was trying to slog through… et voilà!http://www.
com/2014/03/14/the-system-711-how-to-become-a-web-developer/Okay, so you’ve written a function/program/website, and it doesn’t work.
Hopefully it’s giving you an error message somewhere — your testing environment, your terminal, the browser console.
You copy and paste this into Google, and blindly click on results, but they’re all either completely obscure to you or else quite specific and not what you need.
com/thepracticaldev/orly-full-resFirst: is it even worth googling?Some errors are never going to yield helpful search results, especially if you’re writing to a test, like I was in the early weeks of my bootcamp and pre-bootcamp coding.
A non-exhaustive list of “errors” that are more technically failing tests:Error: Expected 32 to equal 173— Nobody else is going to be working with your same function.
Your function is returning data; it’s just returning the wrong data.
That’s a starting point you should be able to debug from (if not, see the next section).
Error: Expected undefined to equal 173 — Still not google-worthy, but now you can see that your function is not returning anything.
Count your curly braces, brackets, parentheses, quotation marks…TypeError: Cannot read property ‘keyName’ of undefined — careful, this one will yield Google results; they just probably won’t be relevant to you at this stage.
Note that the property named is nearly always the key on an object; your problem, then, isn’t with the key but with the object itself!.Keep this in mind as you look over your code.
Your best bet for errors like these is probably to identify where the problem truly is and/or read over the problem/specs carefully, paying particular attention to what you’re actually telling the computer to do, not what you intend for it to do.
com/319/How can I parse my errors before hitting up Google?Sites like PythonTutor take you through your function one step at a time, visualizing how the machine reads your input; rubber duck debugging is also surprisingly helpful, especially for undefineds.
Does your error contain any numbers at the end of the line, like (22:14)?.These direct you straight to source of the problem!.You don’t have to figure it out yourself; in this example, just head to line 22 and look at character 14, and voilà: whatever’s there is what the machine can’t read.
What about those 8+ lines nested beneath your error itself?.It can be immensely helpful to learn to read the stack trace, in time, but for now we can just sift it for the most immediately useful information.
Most of the lines in the stack trace may refer to files you didn’t create (node_modules or something built-in, for example), but there’s usually at least one line where the filename is some file you’ve actually worked in.
This filename will end in a line number, giving you an exact pointer to where the problem is — or, at least, to the first time your program hit this problem.
com/jacojI have no error message; what do I search?If you can’t get to the root of the problem, you’ve still got two very powerful tools at your disposal: console.
log* and the debugger.
log(‘explanatory string’, variable) — Sprinkling these in relevant places in your code can be an excellent way to test 1) what the data looks like in the middle of the function, 2) whether a part of the function is even being run, 3) whether the data being returned is the same type it’s supposed to be, and much more!.I love this method for pinpointing exactly where and how my programs are going wrong.
However, they can quickly become unwieldy, especially if unlabeled or if left in the code after the bug is resolved.
And there’s nothing worse than someone else’s console logs left behind in shared code.
Debugger — Every browser console has a debugger function, as does every IDE (and PythonTutor does something similar).
These permit you to watch, step by step, as the computer executes your function, demonstrating clearly at what step your function is breaking, and what value the computer is receiving for each variable instead of what it should be receiving.
This is a must-have for every programmer’s bug-detective kit.
* Every language has these, under some name or other: print, puts… the point is that it sends data to the console for the developer to read, behind the scenes.
I expect you already know the relevant command in your language of choice.
com/1163/Are we finally ready to search yet?Okay, after you’ve reasonably exhausted your more basic options — or if you’re feeling lazy and choose to skip some of them (I don’t judge; I just don’t vouch for the relevance of the results in that case) — we’re ready for Google.
But let’s do this efficiently; what’s the best way to bring up relevant results on the first page?https://github.
com/thepracticaldev/orly-full-resNarrow the scope of your search: What can you figure out about the root of the problem?.Phrase that concisely, as generically as possible, with appropriate jargon.
Results appear outdated?.(More on how to tell this below.
) Append @2019 to your search string to prioritize recent results (or whatever the current year is — hello readers from the future; I’m flattered you still find this useful).
Before naively searching your error message, delete your filenames and variable names, or replace them with *.
This is especially important (the *) if you decide to enclose part or all of the error in quotation marks.
Great, we’re at where I started before reading this, thanksWell, If you’re feeling that impatient, I hope you just skipped the bits above!.(But we’ll talk about skimming in a moment.
) Now let’s look at which results to click on and how to figure out quickly whether they have anything to offer you.
Occasionally you figure something out just by looking at your list of results, before even having to click on any!.Usually that conclusion is just that your search terms were unhelpful, either too narrow or too broad.
(See the next section.
)Conventional wisdom suggests the following hierarchy of programming websites:Official documentation of the language/library/whateverStack OverflowMedium, Github gists (tie)Reddit, other blogs (tie)So let’s take a look at these.
Wherever you go, it’s tempting to open a page and just begin reading, but we can be more efficient than that!. More details