Handling Nulls in Linx

Checking for null values in Linx can be a real lifesaver—especially when working with objects that may or may not have values. This applies across various areas in Linx, including:

  • Types
  • Input Parameters
  • Query or Function Returns
  • Any scenario where a value might be missing

:stop_sign: Common Error: Null Reference

A typical error message you might encounter is:

Object reference not set to an instance of an object.

This usually happens when trying to access a member of an object that hasn’t been instantiated.

Example:
In the example below, we attempt to assign a value from a string where the parent object MyType is null. This leads to the error, as shown in the image.

:white_check_mark: The Solution: Null Checks

To resolve this, perform a null check on the parent object using the null-conditional operator (?.).

Updated Expression:

=$.Parameters.MyInput?.A

By adding the ? after the object name in the Expression Editor, Linx will safely check whether the object exists. If it doesn’t, it returns null instead of throwing an error.

:bulb: Pro Tip

This approach works particularly well with logic structures like IfElse, Loops, and others where nulls might affect flow control.

:warning: Important Note on Value Types

In Linx, value types such as:

  • Int
  • Decimal
  • Boolean

…cannot be assigned null under any circumstances. If you attempt to assign a null value to one of these, Linx will throw a runtime error. These types must always receive a non-null value.

To safely handle these cases, you need to implement logic that ensures a fallback value is used when the source may be null.

Example using a conditional expression:

=$.Parameters.A?.A == $.System.Null ? 0 : $.Parameters.A.A

In this example, if A?.A is null, we assign 0 instead. This ensures that a valid integer is always used, avoiding the null assignment error.