You instead need to be assigning it directly to the list:
List<User> ccUsers = [SELECT Id FROM User WHERE ContactID = :joint.contact__c AND isActive = true LIMIT 1];
if (ccUsers.isEmpty())
{
//Do something because we found no matching Users
} else
{
//Do something else because there is a matching user
}
The results of a query are never null. An individual record at a given index in the results list will also never be null. Individual fields, however, can be null if they contain no data. If there are no leads the database, the first and second example are basically the same, except that one uses a query towards the governor limit.
Also, leadList2
is not an "empty string" (this has a specific meaning, namely an Object that is a String with a size of exactly zero). It simply happens to be rendered as an empty list via String.valueOf
for debugging purposes. leadList1
and leadList2
, in this example, are equal to each other (leadList1 == leadList2
).
Edit: It's also not correct to say that you have a null list. A list is never null. The variable might be null, but a list itself is not null. Null is just null, and also has a specific intrinsic meaning. The following code demonstrates that there's no difference between a variable that's an uninitialized List versus an uninitialized Integer.
List<Lead> leads;
Integer anInt;
System.assertEquals((Object)leads, (Object)anInt);
By casting both variables to a common Object, we can see that null is always null, because it does not have a "type" in the common sense that other objects have types. There's no difference between a "null list" and a "null number".
Best Answer
The straight SOQL
accounts = [select id, .. from Account ...]
always returns a list
You can usually avoid even having to test for list empty by coding your methods to accept lists as arguments and otherwise use for loop processing as in
Otherwise use
accounts.isEmpty()
oraccounts.size() == 0
testing for null is unnecessary in a well-designed application that uses lists and maps as the core internal data structures. Personally, if I ever get a null value for a list, I prefer the null exception to occur during unit testing as it means I didn't design my code correctly to operate with lists throughout (or I forgot to init a list to empty).
N.B.
For DML, you never need to test for list empty as SFDC will do nothing if passed an empty list
Use:
Don't use (wastes a line of code):