The Dynamics AX Debugger doesn’t support conditional breakpoints. Once in a while this limitation can be quite annoying – but there is a simple workaround. The third trick in the series of X++ Debugging Tips and Tricks shows you how.
This trick requires code instrumentation – I strongly discourage using this trick on a production system. Only use this trick in a test or development sandbox!
By using the breakpoint keyword, you can write X++ logic that triggers a breakpoint exactly as you want.
Consider this example. It is a recursive implementation of the mathematical function: Factorial. On a 32 bit system it will overflow when called with a sufficient high value. The example shows how to a breakpoint when an overflow occurs.
static void ConditionalBreakpointExample(Args args)
int factorial(int _value)
int result = 1;
for (i=1; i<=_value; i++)
result = result * i;
if (result < prevResult)
breakpoint; //Overflow occurred
prevResult = result;
The same approach can be used in many other scenarios too. Here is another example – I’d like a breakpoint to fire when a Released Product with Item Id “1000” is inserted in the database. To achieve that I add the following to the insert method on the InventTable table.
if (this.ItemId == "1000")
There is another way to achieve the same result. You can also insert a no-op line, like i=i; and set a normal breakpoint on that line using F9. This approach has the benefit that only the user setting the breakpoint will hit it – but at the risk of leaving some “silly looking code” behind. In contrast the breakpoint statement triggers a best practice error – so they are easy to clean out again.
There is another usage of the breakpoint statement. Sometimes regular breakpoints in forms don’t fire – here the breakpoint statement also comes in handy. Instead of setting a breakpoint using F9 – just type “breakpoint;” in the code. This will trigger the debugger.
This post is provided AS-IS, and confers no rights or warranties.
Cumulative Update 7 for Dynamics AX R2 has been released today! Download it from Partner Source or Customer Source.
Besides 60 country specific regulatory updates and many quality improvements, these areas have been enhanced:
Inventory and warehouse management
Procurement and sourcing
Product information management
Project management and accounting
Sales and marketing
Backup and recovery
Data import, export, migration
Sales tax processing
In the first trick we saw how to set a breakpoint in the add method on the info class. This enables us to get the context of a single error. But sometimes error messages come in hoards and stepping through each of them is not practical. Suppose you have hundreds or even thousands of errors occurring, and you want to trace where they are coming from. This trick shows you how. This trick requires code instrumentation – I will strongly discourage using this trick on a production system. Only use this trick in a test or development sandbox! The system APIs available in Dynamics AX are fantastic. There is hidden gem of an API that gives access to the current X++ call stack in the form of a container. This makes it relatively simple to include the call stack in the error messages shown in the Infolog. Just insert this line of X++ code in the add method in the info class just after the variable declaration section:
_txt += con2Str(xSession::xppCallStack());
Now run the scenario, and inspect the Infolog. It will include the call stack for each message, and will look something like this:
With this information it is much easier to browse through the many messages in the Infolog and find variations in the call stacks.
I hate debugging - I would much rather write code or watch tests execute! Debugging is a waste of time, and often follows an unpredictable path. Any developer knows the situation: A bug is discovered, and the cause must be found. Most developers have these war stories on how they fought with a bug. The battle swung back and forth. Theories were tested and discarded, instrumentation was built, log files were examined, Murphy visited and, coffee was spilled. When the stories are told, they typically have a happy ending, so eventually the Eureka-moment occurred and the cause was found. And a debugging lesson was learned.
One of my toughest debugging session spanned almost 2 weeks. My code was complete and ready for check-in. I had worked on it for about 2 months in a private branch. Before reverse integrating into the main branch I ran all unit tests. A successful run takes about 12 hours. In my case the execution crashed after about 10 hours. I tried to run the single test case that crashed in isolation. It passed. I tried again with the full automation. It still crashed. I then tried disabling the crashing test, just to realize 10 hours later, that now a different test crashed. I then tried running with a debug version of AX32, so I could debug the crash. But the debug build is much slower, so it would take ages before the crash happened. So I needed to isolate the crash in a simpler repro. I tried changing the order of tests, and with every change I made the crash moved somewhere else. I then began trawling the system logs for information about the crash. This lead me to think about memory – perhaps something was leaking memory. I instrumented the test automation, so it would dump the current memory footprint every 10 seconds to a log file. And yes – memory consumption climbed until the crash occurred. But hey; I’m just writing X++ code – what can I possibly do that causes memory to leak? Driving home one day I got the idea that perhaps it was not my code, but the X++ runtime. After all; I was using some of the not-yet-released-at-this-point X++ features pretty heavily (attributes and events). So I wrote a small job, that exercised these areas heavily, and I saw memory climbing slowly but steadily until the crash. Now with a simple repro in hand, it was not hard to solve the issue – but I did require help from my friends in the X++ team. Two weeks had passed before I was ready to submit, my code was exactly the same, and now all test passed.
This X++ debugging series of posts is dedicated to share X++ debugging tips and tricks. Having a toolbox full of different ways to attack bugs is required to be a productive developer. I’m going to share some of my tricks. If you have tricks of your own, please write a comment, and I will include them in the series. The ultimate goal is that we all efficiently find and solve X++ bugs.
Trick #1 – Breakpoint in Info.add()
Trick #2 – xSession::xppCallStack()
Trick #3 – Conditional breakpoints
Trick #4 – Reading uncommitted data
Trick #5 – To be announced
This trick is probably the first every X++ developer learns, so it deserves to be the first on the list of X++ Debugging Tips and Tricks.
Suppose an X++ exception occurs and you want to know why. The error is written to the Infolog. Double-clicking the line in the Infolog window will bring you to the line that threw the exception. Sometimes it is trivial to see the cause just by looking at the code. Other times it is not, and you will need the entire context including the call stack and variables to figure out what the cause is.
Set a breakpoint in the add method on the Info class – and rerun the scenario. When the exception is thrown your breakpoint is hit, and you can perform the autopsy.
I recently joined the A SCM Inventory team at MDCC – so let me direct your attention to a significant improvement in CU6 in the Inventory area.
Please follow this link:
Microsoft Dynamics Lifecycle Services are designed to manage and optimize customer implementations – powered by Azure. The customer creates project workspaces for implementation, upgrade and maintenance activities, and will invite implementation experts from partner organizations and Microsoft into these workspaces for the execution of related activities. Partners will be able to create projects for learning and presales purposes. This enables partners to build out expertise around Lifecycle Services, and demonstrate this in sales cycles.
Take it for a test drive @ https://lifecycleservices.dynamics.com.
Business process modeler
CODE & UPGRADE ANALYSIS
License sizing estimator
Update 4th of August 2014: Clarification of the AX runtime behavior when non-developers hit an assert statement.
“In computer programming, an assertion is a predicate (a true–false statement) placed in a program to indicate that the developer thinks that the predicate is always true at that place.”
What would you rather have: A piece of source code with or without assertions? I’d definitely prefer source code with assertions – it makes the code easier to read, debug and troubleshoot.
My recommendation is to use assertions in X++ when all of the following are true:
Assertions and error handling are two different things.
In a nutshell, it should be possible to write unit test for error handling – but not for assertions.
Assert statements takes time to write and read – and if the condition they are asserting is obviously always true, then the assertion is pure clutter – and we are better off without it.
A failing assertion is an indication of a problem with the implementation. Something within the component – regardless of input from the outside world – is broken and needs fixing. Typically, I’d use assertions for input validation in private methods, and exceptions in public methods. Conversely, you don’t want consumers of your component to be hit by assertions – regardless of how they use your component.
Assert statements in X++ are a little special, as the X++ compiler always includes assert statements. In other languages (like C#) you can have multiple compiler targets – and typically the release build would not include the assert statements. In AX when a non-developer is hitting an assert statement, then the runtime will suppress eventual errors. I.e. in a production system assert statements have no functional impact.
Given assert statements in X++ are always evaluated, and thus degrades performance, they should be used with a bit of caution. If the condition can be verified with minimal overhead – for example that a variable has a certain value – then there is no problem. However; if the assertion requires execution of complex logic, RPC or SQL calls then it should be avoided, due to the performance impact. In cases where the performance impact is significant, but you don’t want to compromise on assertions, the assertions can be wrapped inside a call to Debug::debugMode().
“without any method calls” is just a guiding principles. Sometimes it makes sense to factor the condition into a Boolean method – for reuse or for clarity – here I would not object.
Here is an example of good use of assertion in X++:
private void markDetailRecordAsEdited( RecId _journalControlDetailId, RecId _draftConstraintTreeId)
Debug::assert(_journalControlDetailId != 0);
Debug::assert(_draftConstraintTreeId != 0);
if (! modifiedDetailRecords.exists(_journalControlDetailId))
modifiedDetailRecords.insert( _journalControlDetailId, _draftConstraintTreeId);
Here is another example where Debug::debugMode() is used:
private void render()
Debug::assert(this.hierarchyCount() > 0);
Debug::assert(segments != null);
Debug::assert(totalSegmentCount > 0);
I once saw a t-shirt with this print on the front: “If debugging is the process of removing bugs, then programming must be the process of putting them in”. I wish the back had read: “Programming with assertions is one way to keep bugs out.”
Read more here.
There is a coding pattern that has been proliferating the X++ code base for years. It is not an X++ best practices – nor is it object oriented; yet it is used quite heavily (unfortunately). Consider a simple class hierarchy with an abstract base class and 3 derived classes. A typical implementation of a factory would be a static method on the base class, like this: (Please ignore the type of the parameter – it could be anything, I choose str for simplicity)
Now; the problems with this approach are many.
The coupling between the 4 classes spells trouble. If you try to modularize an application written like this, you will quickly realize that the pattern above is bad. You cannot have references from lower-level models (aka. assemblies/modules) to higher-level models. Yet; having a single factory method is valuable and a good practice.
SysExtension Framework to the rescue.
Consider you decorate the subclasses with an attribute, like depicted here:
Then you can rewrite the factory method to this:
The extension framework returns an instance of the right subclass automatically. It uses the attribute to determine which subclass instance to create. Quite simple – extraordinary powerful!
A few words of caution: There is a small performance impact on cold systems when using the SysExtension framework. In most cases you will not notice it; however – for performance critical paths, you should measure the impact of this change before going for it.
To learn more about the SysExtension framework see here.