When attempting to fetch a single record from the database it is easy to run into the above exception. I’ve seen two schools of thought in dealing with this issue – mostly in the forums – and have been hoping to find a more official standpoint.
I’ll describe the patterns and perhaps you can help me decide.
The Try-Catch Pattern
- Surround your query by a try-catch block.
- Fetch the record into a single object type variable.
- Either the query successfully executes, or the exception is caught and you deal with it appropriately.
An example,
MyObject__c obj;
try{
obj = [SELECT id FROM MyObject__c WHERE name=:previouslyDefinedVar];
} catch(System.QueryException e){
// Perform logic here
}
The ‘Only Use Lists For Query Results’ Pattern [Made the name up myself. True story.]
- Fetch records into Lists of objects. Do this even if you only expect a single row to be returned. [Queries that return values into Lists do not throw the above exception]
- Check the size of the list(perhaps with an if-statement) and only perform required actions on the record if the list has a size of 1.
List<MyObject__c> objects = [SELECT id FROM MyObject__c WHERE name=:previouslyDefinedVar];
if(objects.size()==1){
// Perform Logic
}
Personally I prefer the first approach. I’m not even really sure why, it just feels less hacky and more readable to me. Perhaps I’m wrong and you can point out why.
I agree with you regarding the first approach. It does feel less hacky and even I might say, more gooder.
I agree with you regarding the first approach. It does feel less hacky and even I might say, more gooder.
If you use the first method, then how are you going to know if an error occured? We cannot be in front of the comp checking debug logs all the time – esp when the code is in production. Would you have an outbound email sent out when the exceptions is caught?
That’s a good point. However I’m not really sure it applies to this situation. The second method wouldn’t yield any error either, and it could be argued that your code should be well tested before it goes into production, and therefore relatively error free.
Of course no code is perfect so I would suggest doing more than coding system.debug() messages within the exception handler. Perhaps adding an informative error message using ‘ApexPages.Message’..
If you use the first method, then how are you going to know if an error occured? We cannot be in front of the comp checking debug logs all the time – esp when the code is in production. Would you have an outbound email sent out when the exceptions is caught?
That’s a good point. However I’m not really sure it applies to this situation. The second method wouldn’t yield any error either, and it could be argued that your code should be well tested before it goes into production, and therefore relatively error free.
Of course no code is perfect so I would suggest doing more than coding system.debug() messages within the exception handler. Perhaps adding an informative error message using ‘ApexPages.Message’..
I use both but have shifted to the first approach for all queries that expect only a single result back.
I use both but have shifted to the first approach for all queries that expect only a single result back.
Assigning the result of a SOQL query to a single object instance is part of the language and therefore is there to be used.
In my opinion makes the code easier to read and maintain.
I guess that this is one of the “structural vs literate programing” arguments.