Collectible Errors?! Is it already in use?
This is the second part of my new article series about Collectible Errors. Let’s check out the first part here: Collectible Errors?! | Microsoft Dynamics 365 – Ing. Tomáš Kapitán (kepty.cz) or you might be interested in my very first article about collectible errors from the last year ErrorInfo data type & Collectible Errors | Microsoft Dynamics 365 – Ing. Tomáš Kapitán (kepty.cz).
This article is focused on how ErrorInfo data type and collectible errors are used in Base App by Microsoft’s developers. Let’s start!
Is it already used somehow?
So lets start trying to find how many variables of ErrorInfo data type exist in the Base App. I used source codes from the Microsoft Dynamics 365 Business Central 2022 wave 1 (W1 version).
As you can see, there are only 8 (eight!) places where the ErrorInfo datatype variable is created. To be honest, I expected it will be already used much more as in my opinion this data type is undoubtedly useful.
Now let’s extend our search not only for data type but also for other places where ErrorInfo is used.
297 results in 24 files… This looks better, especially for functionality being in the system for only nine months now… But why are there only eight places including ErrorInfo data type, but so many more without created variable?
The reason for this difference is easy to find. When you check the documentation for ErrorInfo Data Type you find out that there are two methods (or only one, overloaded) that can be called on the ErrorInfo data type, not on the instance. Instance? What does it mean in AL Language? Instance in AL language is variable, so these two methods do not need a variable.
So in which processes have Microsoft already used ErrorInfo? Let’s see…
There are some internal or special objects (such as journal background check codeunits, integration objects, attachment objects, personalization, etc.). But there are also some essential objects such as Customer and Vendor table, Sales & Purchase headers, or Sales & Purchase Posting codeunits. Let’s check them.
For example, one usage of the ErrorInfo data type in the Customer table:
procedure CustBlockedErrorMessage(Cust2: Record Customer; Transaction: Boolean)
var
"Action": Text[30];
IsHandled: Boolean;
begin
IsHandled := false;
OnBeforeCustBlockedErrorMessage(Cust2, Transaction, IsHandled);
if IsHandled then
exit;
if Transaction then
Action := Text004
else
Action := Text005;
Error(ErrorInfo.Create(StrSubstNo(Text006, Action, Cust2."No.", Cust2.Blocked), true, Cust2, Cust2.FieldNo(Blocked)));
end;Surprisingly, the ErrorInfo is used as the parameter of the Error() method, in the same way as you can use the Text data type together with Error() method. But what is the reason why they used the Error(ErrorInfo) method instead of the Error(Text) method?
As you can see, there are 4 parameters used in ErrorInfo.Create(…) method. These parameters can enhance the information the users (or better, admins) can use to find out more information about the error. But also, there is the second parameter I already described in the previous part of this series – whether the error is collectible. In this example, the error IS collectible. That means when you (or Microsoft) write methods that collect errors, you can use the same method to loop through all customers and get the list of all blocked customers without raising the error.
Let’s try another example: Sales-Post codeunit.
In this example, there are much more places using the ErrorInfo data type. Many of these are TestField methods (check my previous article if you do not know how/why to use TestField(Field, Value, ErrorInfo) method instead of TestField(Field, Value) method). As ErrorInfo.Create() creates a collectible error, all these TestFields can be collected by the caller. And where are collectible processes?
It’s also easy to find places that collect errors, as all these methods need to be decorated with [ErrorBehavior(ErrorBehavior::Collect)] so… We can see there are only 7 objects (8 including base app tests) that collect errors. All these objects do background validation of inserted values to the document or journal and test the value. These tests include “posting preview” (not exactly the preview we know from the system, the process just tries to post the document, collects all errors that are raised during posting, and shows them to the user in the Factbox).
It still looks like there is plenty of processes where it can be very beneficial so let’s hope Microsoft will continue changing standard errors to collectible errors.
