list.IsEmpty() vs list.Size() > 0 vs list != null

  • I want to check the list is empty or not if not proceed further. So, which is preferable in apex and what are the differences between them?

     if(myList.size() > 0) or 
     if(!myList.isEmpty())  or 
     if(myList != null)  
  • sfdcfox

    sfdcfox Correct answer

    6 years ago

    Generally, your lists should always be initialized. One common misconception is that queries can produce a null list, which is never true.

    For example, consider the following code:

    Account[] records = [SELECT Id, Name, AccountNumber FROM Account];
    if(records!=null && !records.isEmpty()) {
        for(Account record: records) {
            // Do Something Here

    This is a waste of CPU time, because (a) records will never be null, and (b) iterating over an empty list is acceptable. Therefore, none of the three checks you might use are rarely appropriate. The only exception to this rule is when one query is used to fuel another query, in which case you would check for the presence of values before performing the query:

    Account[] accounts = [SELECT Id, Name, AccountNumber FROM Account];
    if(accounts.isEmpty()) {
    Contact[] contacts = [SELECT Id, Name, Email FROM Contact WHERE AccountId IN :accounts];

    For lists you create yourself, you should always initialize them before using them. This is true for other types, like sets and maps, as well. There are, however, times when you'll need to check for a specific condition before using some lists. It helps if you experiment with the various types to get a feel for when you should be aware that a list may be null.

    For example, consider a variable that binds to a multi-select picklist:

    public String[] selectedValues { get; set; }

    In this case, selectedValues will either be null, or will not be empty. You only ever need to check for != null in this case. Part of becoming an efficient developer is recognizing the patterns in a system. If you're still using myVar != null && !myVar.isEmpty() as a condition, that generally means you're making one or even two checks too many.

    There is always one correct condition to use in every situation. If this isn't true, that suggests that values were not properly initialized elsewhere.

    sometimes, for your second code snippet; I might have `Account[] accounts = [SELECT Id, Name, AccountNumber FROM Account];` `Contact[] contacts = !accounts.isEmpty() ? [select id, name, .. from Contacts where accountId in accounts] : new List();` in case I need to keep going down the method for other things - knowing that my code can handle either empty account list or empty contact list

    True enough. Sometimes you need to continue, sometimes not. The basic premise is that this should be the only time you need to even see if the list is empty, because it usually doesn't matter.

    why should we always initialize lists or other types like sets or maps ?

    @Walker Perhaps "always" is too strong, but nearly always (>99% of the time). A null variable simply means "we do not yet know the state of something." Most variables should generally not be in this state by the end of your constructor, because you should know your operating state by then. The usual exception are things like processing JSON or XML payloads, because the source may have been null, but for all other cases, your variables shouldn't be null. If they are, they are generally useless, which implies wrong scope.

    i think if we initialize a variable of any type, some resource will be consumed. So i initialize with null, which is implicit as well, and assign it with result of some method, and then while using it, check if it is not null. is there something wrong with this approach in salesforce / apex ? i think return type of SOQL is never null, so if we assign an initialized list with SOQL result, we check for its size >0 and even if its uninitialized, checking for size may not be an issue due to the type SOQL returns, but if we assign a list with value returned by another method it ma y be an issue.

    See articles such as Null checking bloats code. Avoid bugs.

License under CC-BY-SA with attribution

Content dated before 7/24/2021 11:53 AM

Tags used