I have two websites with tutorials and guides for beginning C# developers. About once a week, I get a message from someone having a problem with a lesson. They’re getting an error message and don’t know how to fix the program.
In most cases, if you know how to read the error message, you can quickly find the source of the problem – and the solution.
I’ll be talking about C#, but you should be able to use these techniques with most modern languages.
First, the “exceptions” (the term C# uses for runtime errors) usually have a “stack trace”. This is path the program to to get to the line that had the error.
For example, the stack trace will tell you the program went through this flow:
– It was on line 123 of the Order class, when it called the CalculateTax function.
– On line 42 of the CalculateTax function, it called the RetrieveTaxRateFromDatabase function.
– On line 99 of the RetrieveTaxRateFromDatabase function, it had the error.
Now you can look at the exact line where the error occurred and think about what might have gone wrong on that line. This is easy to do when you do the next step – read the error message. Error messages usually provide a good description of the source of the problem.
In the stack trace example above, line 99 might be the line that calls the database, to get the sales tax rate. The error message will probably tell you something useful, like:
– “Unable to connect to the database”
– “Invalid user name or password”
– “Null reference exception” (the program expected a value, but there wasn’t one)
A majority of the time, reading the error message makes it clear what the problem was.
However, sometimes the error message is not clear. A quick search in your favorite search engine usually provides potential solutions. When I encounter an error message that isn’t clear, I’ll search for “C#” (the language I program in) and paste in the error message. 90% of the time, that gets me a solution.
If I can’t see the obvious source of the error, and I can’t find a solution through searching, the debugger is the step. The debugger is an important tool to learn how to use.
Using the same example, if I couldn’t find a solution, I would set a breakpoint on line 98 of the function. Then, when I run the program again, it will pause on the line before where the error happens.
This gives you the ability to investigate the values used in the line where the error happens. If line 99 passes in a product code, check the value of the product code variable. It may be missing or incorrect – causing the error.
Between reading the error message, following the stack trace, and setting a debugger break point to investigate values, you should be able to find the source of a majority of errors. This won’t get you a solution 100% of the time, but these skills will be extremely helpful.
This is especially important when starting out as a junior developer.
When you start your first programming job, you will hopefully be on a team with more-senior developers. It’s expected that you’ll need their help at times.
However, when you encounter an error, you don’t want to immediately ask a senior developer for help. They’re going to ask if you did the research above, and send you back to do it if you answer, “No.”
A large part of moving from junior developer to senior developer is the ability to solve your own problems.
Return to “Life as a programmer outside Silicon Valley” index