function readOnly(count){ }
Sign Up ›
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
Learn More

Browse by Topic
ShowAll Questionssorted byDate Posted
+ Start a Discussion
Steve BerleySteve Berley 

try catch & execution speed

I've got some code that's throwing errors that provide no information of value.  I wrapped it in a try/catch block to catch the exception at the source so I can isolate and correct it, but its now throwing CPU time outs.

So I've gotta ask - are try/catches super processor intensive? 

Also - tips for working around this would be greatly appreciated...

Thanks,
Alain CabonAlain Cabon
Hello Steve,

Without try/catch, when an exception occurs, code execution halts.

With try/catch, it will all depend on the contents of the catch/finally blocks (and their code) and the try statement that identifies the block of code in which an exception can occur.

Do you continue to halt the execution at the first catch/finally? otherwise, the execution will continue until the CPU time out perhaps (given that you handle most of the exceptions now with a simple System.debug).
  
} catch(Exception e) {
    System.debug('Exception caught: ' + e.getMessage());    
}

https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_exception_types_catching.htm
 
James LoghryJames Loghry

Try / Catches themselves are not CPU intensive. However, if you have a lot of logic in your catch statement, they can become CPU intensive.  

The Apex CPU limit exception you mentioned above, along with a handful of other exceptions including Internal Server Errors, are not catchable.  Therefore, it's possible that the code in your try block is non-performant, even though it seems like it's coming from the catch block.

Look for any loops that could be dragging, or any long running queries or callouts, as those are the likely culprits of your CPU timeout exception being thrown.
Steve BerleySteve Berley
Thanks to you both for your insights.

While I didn't get to use your suggestions to isolate the problem, I did discover the root cause.  An admin created a process builder builder script that caused havoc on record saves to the lead object.  Once it was neutralized all problems went away.