The first of a series of posts relating to new advancements in the Apex language of particular relevance to technical architects.

From a debugging perspective the Apex language lags behind its modern language counterparts. Standard features such as breakpoints (conditional or otherwise) and edit-and-continue are lacking, due to the challenges of pausing runtime execution in a multi-tenanted environment. The typical debug workflow has therefore involved the use of copious amounts of..
[sourcecode language=”java”]
System.debug(‘MyVar value is:’+myVar);
[/sourcecode]
.. statements and plenty of patience. In a development or QA org this is inefficient at best but workable. In a production setting however, deploying instrumented code to assist in diagnosing a runtime issue becomes incredibly time expensive – remember unit tests have to run. With Spring ’12 however the enhanced Developer Console, nicely renamed from the old System Log title, provides a far more efficient approach – Simulated Breakpoints!

In short, a breakpoint can be set on any line of Apex script using the familiar technique of clicking in the sidebar next to the required script line to reveal a red dot indicator. This can be done for all Apex code exposed via the Repository tab in the Developer Console. Subsequent debug logs will capture a snapshot of the heap during runtime execution when the breakpoint is encountered. The snapshots can be found in the Heap Dumps tab within the Developer Console. Not quite edit-and-continue but a marked improvement nonetheless.

This understated capability is a real advancement in debugging Apex script on the Force.com platform. Throw in the other new capabilities such as unbounded raw log access and Visualforce markup editing and it’s definitely time to look again at the Developer Console if you’re doing serious Apex coding.