Introduction: Tips on How to Find Errors in Code (focused on DOS)
Added an easy way to get the error message on step 1.
Hello fellow scripters or curious members, this is my guide on how to spot and fix errors in large, complex code.
This isn't exactly an instructable, as it doesn't teach you how to create something, so if you think there's a better way to communicate it, tell me and I'll do my best.
The basic motives for me to make this 'ible is that in almost every script that I make with DOS, I always make a mistake. So, naturally I began getting good at spotting mistakes, or at least finding out where they are. I wanted to share this knowledge to help anyone having troubles with errors and tedious mistakes within their code. Keep in mind that some of these tips can be used for other languages other than DOS.
Without further ado, let's get started!
Teachers! Did you use this instructable in your classroom?
Add a Teacher Note to share how you incorporated it into your lesson.
Step 1: Error Messages
The first thing I tend to do is run the code a few times, trying to gouge exactly what is making the error. Whether it be that a variable hasn't been defined, or I did a FOR loop wrong. The most helpful thing when trying this method is the error message just before the screen closes. In VBS and Python (I'm sure there's more than that), error messages are there in plane sight, in batch sometimes they are illusive.
The point I'm trying to get across is that if you know what you're dealing with it's going to be a lot easier. For instance, if you're an electrician, and someone calls you saying something like "My light's not working", that's not a lot to go off. I'm not an electrician but I'm pretty sure there's a lot more than one possibility. The whole entire house's power could be off, and they only had the light on, so they thought it was only the light (very bad metaphor).
Here's an easy way to get the error message if the window opens and closes too fast. Navigate to the folder containing the file through the command prompt (cd fiile_path), and then write something like...
start file 2> "error.txt"
start error.txt /WAIT
This will export the error message to a text file which will pop up, and once closed it will be deleted.
Well, I hope I'm able to be understood in my jabbering.
Step 2: Isolate the Error
If you have a 1000 or more lined code, you aren't going to want to search it all for one tiny mistake that caused the program to crash. You need to find the general area of where the error is, and if it is caused by any other code. For instance, you forgot to set a variable, now your FOR loop is mucking up.
This should be really easy in a scripting language, but in a proper programming language, this (I'm assuming, because I don't know any) would be a lot harder. The only problem you would have with this strategy, is if you're dealing with code that you don't understand. Which is why copy, pasting and editing is useless unless you know your way around it first.
Step 3: Finding the Line
So, we've found the area where the error is in, what now?
Well, unless you've mucked up your script in a different area, and the repercussions are only seen in this area, this step will tell you.
I don't know if this method will be any good in any other languages other than DOS, just for the reason of syntax difference.
What I usually do is I put a PAUSE command after every couple of lines, and see where it starts going sour. This should effectively narrow the search area down significantly until you have found the line (or lines) the error (or errors, depending on how tired you were) is in. It should be plain and simple from here on in, you have the line, just fix the error.
If you can't find the error, go back to step one and try to find what's going wrong. Make sure you know how to fix it before attempting, or you'll have more errors, and that's not exactly good.
Step 4: Use Your Brain
Most of the time I know exactly what I did wrong before I even find where it is, just because I realize something that I didn't while writing the original code.
Something I do often while making aesthetics for games is not put escape codes before special characters, mainly the pipe |. Or, sometimes I don't put quotation marks around a string with spaces in an IF statement.
Before completely ruining your code while trying to find the error, browse through the area. Find the general mistakes before attempting the big one.
Step 5: Check Regularly
Sometimes we get a little excited with our script, especially when we're doing something original and ingenious. It's good to be enthusiastic about your hobby/career, but assuming that the idea came to you in the shower or some other medium, you haven't tried it before.
Many a time have I built a whole script on an untested principle.
...What happens when that principle doesn't work? You just wrote that whole code for nothing, so I beg of you, test your theories first!
If you don't, expect it to end in heart break at one point. So get out of the habit of running without looking where you are going, you should always keep a firm grip on reality, and make sure you know what you are attempting is possible.
Step 6: Last Hope
If you can't find the error, ask for help. There's no shame in doing it and it will save ages browsing on the web for a specific article.
It's a lot easier to get an answer from an active member of a community than a website that is totally off topic, but might (just might) have a solution.
Thank you for reading, and I hope you have good luck in the future.