Custom Settings – Null Pointer Exception Quick Fix!

Custom settings in Salesforce are a valuable tool for development, but they can trigger unexpected Null Pointer Exceptions (NPEs) when deployed to new orgs without predefined records. This common issue arises from calling CustomSetting__c.getInstance() without any available data, resulting in runtime errors. In this guide, we’ll walk through a simple and effective solution to prevent NPEs when working with custom settings, ensuring your code runs smoothly across different environments.

Here is the sample scenario that covers this issue and shows the solution:

Custom Setting

The below image shows a Custom Setting named “MyCustomSetting__c” created.

Custom Settings – Custom field

A single custom field named “Config_Field_1__c” is defined for the custom setting above. Please note that its value is defaulted to ‘Hello World’.

Code accessing Custom Setting

Here is the sample code that tries to read the value of the custom setting defined above:

System.debug('MY CUSTOM SETTING VALUE : '  + MyCustomSetting__c.getInstance().Config_Field_1__c);

Upon execution, it will throw a Null Pointer exception if there is no value defined at organization, matching profile, or user level.

The fix to this issue is simple: you can add this single line of code before accessing the custom setting value:

if (MyCustomSetting__c.getInstance() == null) 
  upsert new MyCustomSetting__c (SetupOwnerId=UserInfo.getOrganizationId());

If the custom setting type is “LIST” you will have to change the above one-liner a little. This is because for “LIST” type custom settings, Name is a mandatory attribute.

Here is the code snippet:

if (MyCustomSetting__c.getInstance() == null) 
  upsert new MyCustomSetting__c (Name = ‘MyCustSettingName’, SetupOwnerId=UserInfo.getOrganizationId());

This code just creates an organization-wide value for your custom setting, if that doesn’t exist already. So now accessing this code prints “Hello World” on the console.

Important Notes

• The success of the above approach depends on the way you configure your Custom Setting’s Field. It's highly recommended you create Custom Setting’s Fields with some intelligent default values.

• Create a Singleton class called CustomSettingsHelper to encapsulate all custom settings’ access logic in one place. This will also give you a chance to put this single-liner code in a single place, so that you don’t need to make a call to this one-liner before accessing any custom setting field.

Here is a sample:

public class CustomSettingsHelper {
  
   /**
    The SINGLETON handle to the instance
   */
    private static CustomSettingsHelper self;
  
        
    public static CustomSettingsHelper self() {
      if (self != null) return self;
      
      // To create org wide defaults in new org automatically. This
      // will prevent NPE's in future.
      if (MyCustomSetting__c.getInstance() == null) {
        upsert new MyCustomSetting__c (SetupOwnerId = Userinfo.getOrganizationId());          
      }
      
      self = new CustomSettingsHelper();
      return self;
    }
    
    // No body needs to construct it, a single reference will suffice. 
    private CustomSettingsHelper() {      
    }
    
    // This method can be used to access the custom settings
    public String getConfigField1() {
        return MyCustomSetting__c.getInstance().Config_Field_1__c;
    }
  
    // Client Code that shows how to access the custom setting
    public static testmethod void testCustomSetting() {
      System.assertEquals('Hello World', CustomSettingsHelper.self().getConfigField1());
    }
    
}

Reference

• Learn more about Custom Setting Methods

• Custom Setting Limits and consideration

• Our Salesforce Tool Suite— Chrome Extension (for debugging errors and logging)

Let’s Talk

Drop a note with your queries to move forward with the conversation 👇🏻