LC0084 - StefanMaron/BusinessCentral.LinterCop GitHub Wiki

Use return value for better error handling.

This rule ensures that any database read methods handles its return value. These methods return a boolean indicating whether the record was successfully retrieved. Ignoring the return value can result in uncaught errors, inadequate error handling, and limited feedback for users when something goes wrong. Developers are encouraged to validate the result and implement appropriate error-handling logic.

While the default platform behavior raises an error for failed read operations, explicitly handling the return value improves the user experience by allowing meaningful error messages or corrective actions.

This rule analyzes the following methods: .Get(), .FindSet(), .FindFirst(), .FindLast(), and .GetBySystemId().

Example

procedure MyProcedure()
var
    SalesSetup: Record "Sales & Receivables Setup";
begin
    if not SalesSetup.Get() then
        exit; // gracefully stop executing when setup is not available
end;

procedure GetCustomer(CustomerNo: Code[20])
var
    Customer: Record Customer;
    MyErrorHandler: Codeunit "My Error Handler";
begin
    if not Customer.Get(CustomerNo) then
        MyErrorHandler.EmitErrorInfo(CustomerNotFound, CustomerNo);
end;

My Error Handler

To handle errors consider using the ErrorInfo data type. This provides a structured way to capture and relay detailed error information. For more practical guidance and examples, check out this article: ErrorInfo Data Type & Collectible Errors by Tomas Kapitan.

In certain scenarios, implementing an actionable error can further enhance the user experience by guiding users toward resolving the issue.

Read more: