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.
The next keynote was by Vadim Korepin – who among other things gave Navicon’s expectations to future AX versions.
Vadim is also my host for the conference, and he has been the main translator of the Russian version of Inside Dynamics AX 2012. He has done a great job, and I’m sure he will be tired tonight.
During lunch there was a book signing session. The excitement around the book truly amazed me – I stopped counting how many hands I’ve shaken and how many dedications I’ve written.
Tonight I’m having a tradition Russian/Ukrainian dinner with developers from the Russian community.