One point of discontent among Salesforce developers is the lack of a modern debugger. For a long time now, Salesforce has been talking about how they are working on creating a debugger for code on their platform, announcing their progress at each Dreamforce event. They have still not completely delivered this product. Considering the nature of the Force.com platform, however, this is a very difficult feat.
Why won’t a traditional debugger work in Salesforce? Consider the shared physical resources. When a developer in your org stops execution of some code, by nature of it being a shared database, it is likely that rows in the database will be locked for update. If a debugger stops execution and remains stopped for many minutes, there will be a negative impact on other users who want to update those records. Though this risk is minimized in a developer sandbox, this could leave a bad user experience and inaccurate data.
But, I’m not an expert on debuggers, nor on their implementation. The purpose of this post, rather, is to share with you Salesforce’s latest solution for providing a debugger in their multi-tenant environment.
Traditionally, the function of a debugger has been to allow a developer to step through their program line-by-line, looking at how the variable values are affected each step of the way. This method replaces the older, more primitive method of debugging, called tracing, which is characterized by printing variable values out to an easy location, such as the command line. Tracing, however, is a time-consuming process because of the forethought and trial-and-error process of deciding where to look for a bug. A debugger, on the other hand, allows a developer to explore variable values in real-time by setting a “breakpoint” to stop the code and inspect it. Besides easing the process of finding the actual bug in the code, this also affords the luxury of exploring your code, and possibly find unrelated bugs.
For technical reasons, implementing a full-feature debugger is probably not feasible for Salesforce. Their solution, however, is hitting pretty close the mark. The updated Developer Console finally allows you to place “breakpoints” on a line of code. These aren’t traditional breakpoints that stop execution of the code, rather they can be better described as heap-dumps. By placing one of these “breakpoints” on a line of code in the “Repository” tab and then executing that code, a heap-dump of the values of all variables in scope of that breakpoint is sent to the “Heap Dumps” tab of the developer console.
For most developers, the killer use case for this heap-dump feature is to debug production issues. Previously, the only way to dig into a code problem was to insert debug statements into the code and try to reproduce the error. Direct code changes in production are restricted by Salesforce, so the only way to debug an issue in production was is to create a full-copy sandbox in which to debug. Depending on the severity of the issue and the type of Salesforce org you have, this may not be an economical decision. With the ability to create these heap-dumps in production, however, a developer can reproduce the bug in production, then use heap-dumps to check the code reality against their suspicions. Even if the code cannot be fixed in production directly, the developer has a head-start when it comes to implementing the fix or suggesting a work-around.
For more information, check out the official demo of the new developer console on the Force.com blog. Sandeep has put together a great demo of the new Developer Console that is available to all Winter ‘12 orgs. Keep in mind that the availability of the new features may lag a few weeks behind for production orgs, while it is available immediately for developer orgs and sandboxes.