Oh shit, Another Bug (Getting around bugs/errors).

One thing I have seen a lot is new programmers scared of the next error. it’s like not another error again, where did this come from again. Frankly, I don’t know if I got comfortable with knowing there might be bugs, or maybe it’s because I now understand programming better that I am no longer fazed by them. For certain from the newbie in tech to the most experienced senior developer we all deal with bugs. It’s almost inevitable and can happen to anyone but personally, I have gotten more familiar with bugs and consequently programming techniques and patterns that after I fix the bug, I say to myself “why would I have ever expected this to work in the place”

Important things to know about bugs:

  1. Maybe red is a scary color but bugs aren’t scary, as a matter of fact, bugs are feedbacks. Consider it as your code communicating to you.
  2. Bugs errors are sometimes descriptive. Remember I said it’s like your code tells you something, Yes there will most likely be an error message and an error code. That most times is enough to know what is wrong. You might not know at the time, but the code and message tell you what is wrong.
  3. A good part of it is there is a 99% chance someone else has faced it, it gives you confidence that it can and has been solved, so you too can.
  4. You probably misplaced or forgot something and the code wouldn’t have worked otherwise, you probably did something wrong and it's okay, you just need to do it right
Debugging errors

Practical Steps to Debugging

Get as much info from the console

This might not be applicable in some cases, but this is the fastest way to detect the issue and also a pointer to a possible solution. Error Code, Error message, the file where the bug originated from, Possible solutions to the bug; are some of the information that can be gotten from the logs of an error.

It could just be that you forgot to import a package or file

Find and isolate the bug

Usually, the difference between an experienced programmer and a new programmer is seen at this stage. While the experienced programmer might foresee errors due to complexities, a new programmer might have to wait till testing to see the errors. This is usually the most difficult part of the job because the symptoms sometimes do not define the problems. For instance, if you have a bad input, you might not spot the problem until the system needs to use the input. This might happen long after the input has been read. In such a situation, the symptoms you see might be hard to retrace to the real errors.

You can approach this step in two ways deepening your level of experience. The first method is to create hypotheses as to where the problem might be. If you are an experienced programmer, chances are that you might have seen something related to the present bug. Therefore, your guesses would likely lead you to the bug. Another method is to run through each unit of code (each function or each method or each class) of the program looking for possible problem areas. To find out whether the error occurs before or after a section in the code.

Finding the cause of the bug

After locating the suspected area of the bug, you need to determine what the actual problem is. While trained debuggers might be able to find and isolate bugs, it takes someone familiar with the system to correctly diagnose the source of the bug. Some common causes of errors include the following:

  • External issues like incorrect input
  • Logic errors like in situations where correct data was handled wrongly. E.g., a line seeking the square root of 0
  • Unexpected values are like a situation where the number of entered variables exceeds what was expected.
  • Incorrect reference data and many more.

Once you have found the error, it’s good practice to check other parts of the code for similar errors. You might not bother if the problem was due to a typographical error. However, if the problem was due to a misunderstanding of the design and requirements, there is a huge chance that you repeated the errors somewhere else.

Finding a fix for bug

Now that you have a good picture of the problem, how do you solve it? Now you must be careful fixing the problem so you don't also create multiple problems. For instance, fixing a bug can show you other bugs that you didn’t see before. Sometimes, it might even create entirely new ones that you didn’t realize were in existence before, or you might introduce a new approach that might affect other services or blocks of code depending on your fix.

Therefore, before you proceed to fix the bug, ensure you fully understand the system and how all the parts work especially if it is a design flaw.

The reason is, while logic errors are easy to spot, design flaws cover a larger area and are difficult to fix. In some cases, you might have to rewrite the entire program in other to solve design flaw problems.

Depending on the severity of the problem, a good idea might be to apply a quick fix to the problem. Later on, you consider a permanent solution depending on how pressing the problem is and the side effects of the problem.

Testing

Testing is the last phase of debugging and it is done to see if the fix correctly handles the problem. When testing, ensure to ask the following questions:

  • Does your fixing solve the original problem?
  • Are there any other problems created by the fix?

Usually, testing is a continuous process that goes on until the product is finally released. As you add new features, you need to continue to test to see if the system gives the right results.

Tech — Humor — Live — Love — Grow || Software Engineer || Creator/Host The tech bro podcast || E:ibiyemipedro@gmail.com

Tech — Humor — Live — Love — Grow || Software Engineer || Creator/Host The tech bro podcast || E:ibiyemipedro@gmail.com