Collectible Errors?! Is it already in use?

by Aug 3, 2022AL Language

Home 9 Development 9 AL Language 9 Collectible Errors?! Is it already in use?

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 ( 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 (

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)
    "Action": Text[30];
    IsHandled: Boolean;
    IsHandled := false;
    OnBeforeCustBlockedErrorMessage(Cust2, Transaction, IsHandled);
    if IsHandled then

    if Transaction then
        Action := Text004
        Action := Text005;
    Error(ErrorInfo.Create(StrSubstNo(Text006, Action, Cust2."No.", Cust2.Blocked), true, Cust2, Cust2.FieldNo(Blocked)));

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.

Recent Articles from the category

BC Open Source? How to start?

BC Open Source? How to start?

BC Open Source? How to start? One of the most exciting news introduced last month in Lyon during Directions EMEA 2023 was the changes to the open-source initiative. This means that you can now contribute to the source code of the Base app and the System app, which are...

read more
Validate a FlowField Field. Wait? What?

Validate a FlowField Field. Wait? What?

Validate a FlowField Field. Wait? What? There are not many things in the AL Language that surprised me. However, last week, I found one such thing - I reviewed customizations made by another partner and had to analyze the OOTB code of the Demand Forecast matrix. I run...

read more
Dynamics NAV 2013 & Expired Cronus License

Dynamics NAV 2013 & Expired Cronus License

We found an interesting problem - we were not able to run the development environment for Dynamics NAV 2013. Whenever we tried to run the development client, we got the following error message: "Your program license has expired" and the development client has closed...

read more
Indirect Dependencies and Access Modifiers

Indirect Dependencies and Access Modifiers

Last week, there was a discussion on Yammer on how to get values from the "Sent Email" record when all fields are marked as Internal. I was surprised that many people do not know what can/can't access modifiers (such as local, protected, or internal) be used for. I...

read more

Sign Up for News


Highest certification
Microsoft Data Management and
also in D365 Business Central

Microsoft Certified: Dynamics 365 Business Central Functional Consultant Associate

See other certifications here