You might be familiar with the concept of debugging as discussed by developers. In a previous blog post, we delved into the realm of bug-busting within software testing. In this blog, our Senior Support Developer, Martyn Price, along with Junior Developer Dan Hirst, explore the essence of debugging, shedding light on the methods and tools employed by developers to ensure the seamless operation of software.
What is debugging?
In software development, bugs can disrupt the intended behaviour, causing glitches, errors, or system failures. For a seamless software experience and prompt issue resolution, explore our comprehensive support packages.
To tackle these challenges, we employ ‘debugging’, a method that involves meticulous scrutiny of code and its execution to pinpoint issues. Debugging empowers developers to comprehend programme behaviour at different stages, uncovering flaws. Imagine a complex machine with gears, levers, and switches that should automatically make your favourite ice cream. However, glitches can lead to odd noises, wrong flavours, or breakdowns. Like a detective, debugging involves dissecting the machine, observing its components’ interactions, and identifying the problem. By fixing or replacing faulty parts, the machine – or software – runs smoothly again.
Similarly, computer programmes resemble intricate machines with code, functions, and variables. Unexpected behaviour or incorrect results can occur. Debugging involves analysing these components, rectifying problematic code, and ensuring everything operates as intended.
Examples of some of the tools we use as developers
Logs
When an application encounters an error or behaves unexpectedly, logs play a crucial role in identifying the root cause. We can examine the log entries related to the problem, including stack traces, exception details, and variable values, to gain insights into what went wrong and where.
Example: Timestamp: 2023-07-06 14:30:45 Level: ERROR Message: An unhandled exception occurred during the execution of the ‘ProcessData’ method. Exception: System.NullReferenceException: Object reference not set to an instance of an object. StackTrace: at MyApp.DataProcessor.ProcessData() in C:\MyApp\DataProcessor.cs:line 57 at MyApp.Application.Main() in C:\MyApp\Application.cs:line 23
We can see from this log exception that the process data method is causing the application to break on line 57 of the file DataProcessor.cs. The log message gives us a clear indication that the error is a “NullReferenceException,” which means that somewhere in the ‘ProcessData’ method, an object is being used without being properly initialised. The stack trace shows the chain of method calls that led to the exception, indicating that the ‘ProcessData’ method was called from the ‘Main’ method on line 23 of the ‘Application.cs’ file. To resolve this issue, we need to carefully examine the ‘ProcessData’ method in the ‘DataProcessor.cs’ file, particularly focusing on line 57. We should check for any variables or objects being used on that line and ensure they are assigned valid values before reaching that point in the code.
Breakpoints
Breakpoints are markers or points set by developers within the source code of a program to pause its execution at a specific line or statement during debugging. When the program reaches a breakpoint, it temporarily halts, allowing developers to examine its state, variables, and other relevant information. Breakpoints are a fundamental tool for debugging and troubleshooting software applications.
For example, imagine in a factory setting, breakpoints for bug fixing would be like designated inspection points along the production line. When a potential issue is detected, production is temporarily paused at these breakpoints, allowing factory workers to closely examine the product and identify the problem.
Watches
Similar to breakpoints, Watches allow developers to monitor the values of variables, expressions, or properties during program execution without necessarily pausing the program’s execution like breakpoints.
In a factory, “watches” are like special inspection tools that help supervisors closely examine and understand what the workers are doing at different stages of production. These tools allow supervisors to keep an eye on critical parts of the manufacturing process, ensuring everything runs smoothly and products meet quality standards.
Similarly, in debugging, “watches” are tools that allow programmers to inspect and monitor the values of variables and expressions as their code runs. By setting “watches” at specific points in the code, programmers can observe how the program’s data changes, helping them understand how the program is behaving and catch any issues that might arise during execution. This way, they can make necessary adjustments to ensure the program works correctly, just like factory supervisors make sure the production process is on track and products are of high quality.
Stack trace
A stack trace is a report that provides a detailed trace of the sequence of method calls and their corresponding locations within execution. It shows the call hierarchy or call stack, starting from the point where an exception or error occurs and going back through the chain of method invocations.
A stack trace is like retracing your steps on a treasure hunt. It’s a detailed record of the sequence of function calls that brought your program to a particular point or encountered an error. Just like retracing your path helps you understand your progress in the treasure hunt, a stack trace allows developers to identify the exact flow of their code during debugging. By examining the stack trace, they can pinpoint the source of errors, understand how functions are interacting, and effectively troubleshoot issues in their software.
SQL server profiler
SQL Server Profiling is a tool provided by Microsoft SQL Server that allows us to capture and analyse events and activities occurring within the SQL Server database engine. It helps in troubleshooting, performance tuning, and debugging SQL Server-related issues.
Imagine you are a detective trying to solve a mystery. The crime scene is your SQL Server database, and you need to gather clues to understand what’s happening inside it.
- SQL Server (The Crime Scene): The SQL Server is like the crime scene where all the data is stored, just like how evidence is present at a crime scene.
- Detective (SQL Server Profiler): You, the detective, represent the SQL Server Profiler tool. Your job is to watch what’s happening inside the SQL Server and collect information like a detective investigating a crime.
- Clues (SQL Server Events): Clues are like events that happen inside the SQL Server, such as queries being executed, data being inserted, or errors occurring. These events can tell you how the database is being used and if there are any issues.
- Investigating (Capturing Events): As a detective, you set up your tools to capture these events happening inside the SQL Server. SQL Server Profiler does the same by recording the events as they occur.
- Understanding the Crime (Analysing Events): After capturing the events, you carefully analyse the clues to understand what’s going on inside the SQL Server. Are there any slow queries? Are there errors? It’s like putting together pieces of the puzzle to solve the mystery.
- Solving the Mystery (Optimising Performance): Once you have the complete picture, you can identify potential problems and take actions to optimize the database’s performance or fix any issues, just like how a detective solves the mystery and brings the culprit to justice.
In simple terms, SQL Server Profiling is like playing the role of a detective to investigate what’s happening inside the SQL Server database. By capturing and analysing events, it helps you understand how the database is being used and identify any potential issues or areas for improvement.
Rubber duck
A rubber duck is a highly specialised and irreplaceable tool that every developer must have on their desk. Now, you might be wondering, what role does a rubber duck play in debugging?
A rubber duck is a secret weapon used by developers. Often, we find, by explaining the code we have written to the rubber duck on our desks, uncovers the solution to problems encountered. This unique technique proves that sometimes taking it back to basics and reflecting on what you have created is key. The best debugging partner really is a nonjudgmental, attentive yellow rubber duck!
Are you contemplating enhancements to your system or seeking to develop and test new software? Reach out to us now.
This blog was collaboratively authored by Martyn Price, our Senior Support Developer, and Dan Hirst, our Junior Developer.
