When I can, I always write code, so I had and solved a lot of bugs. Basically I want to share a basic pattern with you on how I solve most of my bugs. It may help you to solve your bugs faster and get the actual work done much faster.
So here are my tips on how to solve bugs:
aka looking at the code. Just looking at the code and explaining each step to yourself can be extremely helpful. I often do this step first. I look for what could've thrown the exception. For example if my exception is IndexOutOfRangeException, then I look for lines in the code that access arrays. Also if you have a debugger you can look at the callstack or traceback.
Callstack (or traceback) is a history of the called functions in the current context.
Let's say for some reason a debugger isn't available so you can't look at the callstack, or the line that threw the exception. Catching error messages and saving them to a logfile can be helpful in this case. Think of the important values that can cause the exception and log them to a file. You can still get an error message from a catch block.
If you really can't find the problem this way, just put different log messages after every line, so you can detect where your code breaks.
This time you have a debugger and you can insert breakpoints in the code and step through the lines of your code.
When the code breaks for the first time remember that function where it broke. Put a breakpoint at the top of the function. Now do the same actions which threw the first exception, but you will break at the top of the function.
Step through the lines slowly and look at each variable that could cause the bug. This is the method where most of my bugs get solved and I can resume working on the application.
So at this point the problem is really bad, it's beyond my knowledge and I have to look at other people's problems. I really hate this step, because this means that you can't solve the challange, but you must do this if the problem is beyond your knowledge. You obviously know stackoverflow and that's what I recommen when searching for issues. Most of the time an accepted answer will work and then you know the key to that problem, so you don't have to use this tactic again hopefully.
In a heavily multi-threaded application it's possible that there's a race-condition. A race condition is when multiple threads try to access the same resource and generate a result based on the resource. The problem is, that this resource can be changed and then the threads won't get the same result. Or another example is when multiple threads depend on each other, but the order of completion is random, so they can't get the required values. You can spot this when the application randomly throws an error. At random time/repetitions/actions. To solve race-conditions you can use locks or in c# you can use the ContinueWith method on a Task if your threads depend on the result of each other.
In some cases like again a multi-threaded application a thread can remain open after closing the application, this will result in you thinking that the application is closed, but one or more of it's threads are still running in the background.
Look in Task Manager (press CTRL + SHIFT + ESC to bring it up), find yourProjectName.exe and kill it.
Yes the good old tech support option, the restart. In some cases some of the applications may conflict with each other, in that case a restart can solve the problem. I haven't solved any issues with this tactic I just tought I put it out there.
Yes I know this sounds crazy, but AVs now days have their network monitoring tools, which can produce unexpected results in your application. For example when I connect to a non-existing mail server I still get a connection, there are just no responses. Why? Because I get connected to the AV's local proxy server!
So this is the last option, you've done everything from debugging to restarting the whole system, and still no luck. At this point there's a high probability that the bug isn't your fault, but the fault of a 3rd party DLL or the IDE. One such example is that Visual Studio 2017 decided yesterday not to reflect Console.WriteLine() calls in the output window.
I walked through the whole list and no luck. Debug.WriteLine() and Trace.WriteLine() aren't working either, so the problem is probably with the IDE. Many people had the same issue, so I just commented on one of the issues.
I hope some of the above options solved your problem, if not, then you found a huge bug, that no one else found before, or knows how to solve. Sometimes finding a new approach to the problem you're trying to solve can solve bugs. Programming is creative and allows you to take multiple routes! Exploit this ability of programming and solve every bug you face!
Thank you for reading this post!
