Avoid These Common Salesforce Array Mistakes

Salesforce development with Apex is fun - until your arrays start acting up. You think you're assigning values or looping through cleanly, and then boom - null pointer exception, array index out of bounds, or even worse, silent failures that take hours to debug. Been there, done that.

If you're working with classic Apex arrays like Integer[] x;, you're not alone. But these arrays can be surprisingly tricky. Let's dive into the common mistakes devs (yes, even seasoned ones) make with Apex arrays and how to sidestep them.

Declaring an Array Without Initializing It

Let’s say you do this:

Integer[] nums;
nums[0] = 10; // System.NullPointerException: Attempt to de-reference a null object

You might expect nums[0] to hold the value 10, but what you actually get is a runtime error. Why? Because while you've declared the array, you haven't initialized it. Apex doesn’t auto-allocate space.

Fix it:

Integer[] nums = new Integer[3]; // Initializes an array of size 3
nums[0] = 10;
System.debug(nums[0]); // 10

Better safe than sorry. Always initialize with a size before use.

Assuming Arrays Auto-Resize

Unlike dynamic collections like List<Integer>, classic arrays in Apex are static. If you try to assign a value outside the initial size, Apex throws a fit.

Integer[] data = new Integer[2];
data[2] = 42; // System.ListException: List index out of bounds: 2

Why it fails: You only created space for data[0] and data[1].

The fix? Either switch to Lists or be super precise with your array sizing.

Misusing the For Loop with Incorrect Bounds

This is a sneaky one. Let’s look at this:

Integer[] values = new Integer[5];
for (Integer i = 0; i <= values.size(); i++) {
    values[i] = i * 2;
}
// System.ListException: List index out of bounds: 5

Looks innocent, right? But you're going to crash on i = 5, because values[5] is out of bounds.

Correct way:

Integer[] values = new Integer[5];
for (Integer i = 0; i < values.size(); i++) {
    values[i] = i * 2;
}
System.debug(values); // (0, 2, 4, 6, 8)

Use < instead of <=. Classic off-by-one error.

Forgetting That Arrays of Primitives Are Null by Default

If you declare:

Integer[] x = new Integer[4];
System.debug(x[2]); // null

What does it output? null.

In Apex, primitive arrays don’t auto-populate with default values like zero. Each element is null until you assign a value.

Pro tip: Always loop and assign defaults before assuming the values are there.

Integer[] x = new Integer[4];
for (Integer i = 0; i < x.size(); i++) {
    x[i] = 0;
}
System.debug(x); // (0, 0, 0, 0)

Thinking Arrays Are Passed by Reference (They’re Not… Exactly)

This one's confusing. Arrays are passed by reference to a point. But if you reassign the array inside a method, the original stays untouched.

Integer[] data = new Integer[3];
data[0] = 5;
modifyArray(data);
System.debug(data[0]); // 99, not 0

public void modifyArray(Integer[] arr) {
    arr[0] = 99;
    arr = new Integer[2]; // This change doesn’t affect the caller
}

Why? Because you're modifying the array content (arr[0] = 99), which sticks. But when you reassign the entire array (arr = new Integer[2]), it only affects the local copy.

It’s like giving someone your address and they rearrange your furniture (that affects you). But if they move to a new house? That doesn't change your address.

Not Handling Null Arrays Before Access

Sometimes an array is null and we don't check for that before using it:

Integer[] arr;
System.debug(arr.size()); // BOOM: NullPointerException

Simple fix:

Integer[] arr;
if (arr != null) {
    System.debug(arr.size());
}

Or better yet, initialize upfront:

Integer[] arr = new Integer[0];
System.debug(arr.size()); // 0

Overcomplicating When a List Would Be Better

Look, if you're doing a ton of insertions, deletions, resizing, or dynamic operations - use a List<T> instead. Arrays are fast and simple for fixed-size needs, but quickly become awkward.

You don’t bring a chainsaw to slice a tomato. Same logic here.

Conclusion

Apex arrays might look familiar if you come from Java or C++, but they’ve got their own quirks. From initialization blunders to boundary issues and misused methods, there's a surprising number of ways to get tripped up.

The trick? Know the limitations. Think of Apex arrays as rigid little containers - super efficient when used right, but absolutely unforgiving when mishandled. If you're finding yourself writing too many workarounds, it might be time to switch to List<T>.

Now that you've got the scoop, go clean up that array code - and dodge those bugs like a boss.

SalesForce Simplified