Bugs lie in hidden places. In programming we get to create as we architecture and create ingenuously by coding a application from ideas but more often than not there is a bug or two hiding withing out architecture waiting to reveal it self at the most inconvenient of times. Debugging is the art of finding out those bugs and eliminating them from the code perfecting the application. making it a masterpiece if you will. There are many ways to spot and error and many tools to aid you as a developer. It behooves you as a developer to take advantage of this tools to make the debugging process as effective and efficient as possible. Often we have a local environment to run, test and debug the application before pushing it to the staging or live environment but sometimes and most especially for legacy solutions, we have applications that for one reason or the other one might not be running on the local environment (I know it might sound incredible nevertheless its true with SITECORE kind of solutions) or bugs that don't real veal themselves in the localhost only to rear their ugly head in the live environment.
This article will focused on the two scenarios:
- An application you can run and debug on the localhost environment.
- An application you have access to the codes but must debugged on the live environment.
Localhost Debugging (Debugging In a local environment):
As it is with all architectures we begin with the presentation layer i.e the view and proceed to the back-end before ending in the database layers. Each of these layers have tool where a software developer can quickly check to find error messages in the application which can give an alert of the problem and more importantly a hint to the required solution.
Setting A JQuery Break-Point:
Stepping through the JQuery code to see the input field values in real-time, one can find out which
variables are throwing an undefined value or giving an error message when reached. Sometimes the back-end runs smoothly nevertheless the code keeps breaking in the view because one input field or the other. Using inspect element and clicking on the source tab in the lower part of the view and putting a break-point on the Javascript or JQuery codes to see what is actually being returned to the view and implementing a solution based on that. It is prudent to solve a view problem in the view with either css, JQuery/Javascript or Html and not pass the wrong value to the code-behind and then attempt to solve the problem there, for one thing it prevents having to reload the page unnecessarily many times when you can simply check the value with Html or Jquery and give the user a feedback/error message if its an input problem thereby making you application faster and more user friendly.
Using The Debugger Syntax:
Its possible that a javascript/Jquery code might not be able to set a break-point at a position in the code you would like or there might actually be a break-point there but still the break-point is being skipped then manually inserting the
debugger syntax in the JQuery code to force the code to stop on the JQuery part at run-time is a good way around this problem. Always keep in mind there a many ways to skin a cat.
Effect: Being able to step through the JQuery codes without needing to set breakpoints in the view as the code will automatically stop at these points when hit. Remember to remove them as soon as you are done as they can equally be a bug on the live environment.
DEBUGGING IN THE CODE-BEHIND WITH AN IDE
Setting A Break-Point In A Method Inside The Code:
Debugging with an IDE (Integrated Development Environment) e.g Visual Studio. We are all familiar with this so I need not dwell on the process. It simply involves stepping through the code till the exception or error message is thrown. At times it might require using a try catch to get the error message in details this is useful when dealing with imported dll's created by others an example is EntityFrameWorks.
Changing The parameter Value At Run-Time:
Another great way to know what is happening where inside the code. Setting a fixed value for a property field or a Boolean controlling a conditional statement might be a great way to see what happens when a particular area of the code is reached.
Using A Watch In Visual Studio IDE:
If you have a variable in the code that constantly changes values like a counter in a for or foreach loop statement, then setting a
Watch can be used to see all the various values that the variable changes into. Also you might not want to see all the values but might only be interested in a situation where the variable value is e.g
2 and in that case a watch can be set for when the value is two and when you run the application it will get into the for loop and halt at the point where the variable is exactly the value you want and you can carry on your debugging from there.
DEBUGGING IN THE DATA ACCESS LAYER/ DATA LAYER
Debugging SQL Stored Procedures:
Just the same as setting a breaking point in Visual Studio but this is done in the Microsoft SQL Server Management Tool or whatever Database management tool you are using. Used mainly for stored procedures and SQL queries in general you set the break-point and when the code hits you begin to step through to find-out where the error is coming from. Very useful then the error has nothing to do with both the presentation(view) or business logic (code-behind) layers but is with when the value is either being gotten from or returned into the database.
Executing The Stored procedure:
In this technique you add the values directly into the stored procedure through the SQL server management studio to see the out puts. Really comes in handy when what you just want to do is work with the SQL query alone and not have to run the entire application and add values from the view in order to see the effect in the database.
Once the stored procedure values and the execute button clicked it triggers the specified procedure and outputs the value which the developer can check to confirm if its selecting or inserting the correct value from/into the database.
Using SQL Profiler Tool:
The SQL profiler is a powerful tool for debugging the data layer as sometimes you might not know which particular stored procedure is being called in a particular method or at what point exactly, the SQL profiler can help here and save you the trouble of running the application and then religiously following each method to found out which stored procedure is called as the SQL profiler displays the queries called making it easier to know what is called and when.
Debugging In A live environment (When the application does not run on the localhost):
Many are times you might not be able to debug the application locally but must run it either in a staging or live environment and troubleshoot it there to discover the error and resolve the issue.
This can seem a monumental task and be really frustrating is one doesn't know how to go about fixing the error. Below are few good ways of debugging the application and finding and fixing the error.
Decompiling The DLL File:
No Code is the grail. It might come in handy to decompile the dll file (if and only if one is not breaking any copywriter violation law) in-order to see what is really going on and either insert a personal code that handles it, add a save method in the code that saves the exception, error message or value at that point in the database or ought right implement the same method in ones code and avoid calling the dll in that instance but implement your own method that also solves the error based on the method on the decompiled code of the dll file. One might even learn a thing or two in the process.
Logging The Error In The Database
Using third party dll's like Elmah a software developer can log run-time errors with the dates/time and then go through the errors to know what is breaking in the application. This could also be useful even when the application doesn't stop working or give and error to the user but breaks internally and continues working due to the fact that the exception is caught in a try catch and the finally kicks in. An error is and error and the objective is to eliminate all bug.
Using Fiddler:
Fiddler is another great product from the Telerik team and this can be used to test API's with POST and GET requests or monitor the error message from a browser when an event is triggered from the view. The same bug might have different error messages depending on the medium used to view it. It might give a partial/summarized version in the view but with fiddler a more detailed error message can be seen when the log of the action is clicked on and examined closely.
Requestb.in can equally be used to test an API. An example of this is during a post of the required data to a payment gateway that doesn't save the response message in a place where the developer can see the status like sandbox, a site like this is the best bet where the generated link will be assigned as the call back URL and then the returned data can be checked.
Mobile View Of The Web App In Chrome:
Some errors are peculiar to mobile versions i.e they might render well in the desktop version of the application and even in one or two mobile devices but eventually fail on another mobile device (a solution I once worked on ran smoothly on a Windows and an Android phone but failed on an IOS) and in this case the best way to go about it is to render the application in the desired mobile version and troubleshoot it from there. By inspecting the element and selecting the various versions of mobile devices using the google chrome browser one can simulate with as many devices as possible and debug accordingly.
Checking The JQuery Console For Error Messages:
The
Colsole tab in the browser after an inspect element has been activated is another place where a developer can see certain errors and carve out a solution from there.
Using Different Browsers:
Just like the difference between the the desktop and the mobile device or to be more concise, even among various mobile devices it is a good procedure to debug the application/solution with different browsers as well not only for how the view renders in the browser but also if an error occurs in a certain browser that doesn't occur in the others. Checking older versions of a browser is not an overkill as its difficult to know which browser the user will be accessing the site with hence due diligence on all fronts is considered a prudent and responsible practice in this case.
NOTE:
Minimizing the size of your browser is not the same thing as effectively checking a page's rendering and functionality in the various mobile views. One should either check it inside the device or use the chrome browser tool to debug that. using notepad can also help to clearly look throught the error message because some times the message is compressed together but when copied and pasted in a notepad file one can easily look through it and separate it out to check the line numbers which are sometimes correctly included in the error message. Setting fixed values to variables to see what breaks is another good way to troubleshoot/debug. Using alerts in the view can sometimes also be helpful when debugging through JQuery codes as this can be used to return values to the developer to see what occurs at what point in the code. Removing the detailed things (number lines, name of solution and methods) that are peculiar to your error message and dumping the rest in google to search for a similar problem and the proposed solution.
Finally when all else fails reaching out by sourcing for help from a colleague or posting the error in a company or general developers problems/solutions forum e.g stack overflow e.t.c can be the last step of the debugging process.
Enjoy!!!
