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
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.
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.
Pro Tip
This approach works particularly well with logic structures like IfElse, Loops, and others where nulls might affect flow control.
Important Note on Value Types
In Linx, value types such as:
IntDecimalBoolean
…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.