Apex Debug - Salesforce
update! this is not an Apex Debugger replacement, is complimentary. Please check the Apex Debugger limits.
Many developers use to remove the debug statements after analizing their own Apex code.
- CPU time
- Reducing the lines of code.
I think it’s not a good practice to clean up your logs, at least not all of them. There are good reasons to keep your debugs on your code.
Why to keep them?
You can skip the time consuming task of having to add some debug lines on your sandbox’s code, deploy it to the Production Org and try to reproduce the same error again.
First of all… please use the LoggingLevel param in your Debug sentences. That is what it is for :)
System.Debug(LoggingLevel.DEBUG, 'Your debug comment');
System.Debug(LoggingLevel.ERROR, 'Your debug comment');
System.Debug(LoggingLevel.FINER, 'Your debug comment');
You have all these options > NONE, ERROR, WARN, INFO, DEBUG, FINE, FINER, FINEST.
This allows you to change the Log Levels directly in Production as you need and start looking for any issue, with no deploys, no delays.
And in case you´re a consultant that has no access to Prod, your customer can send the entire log for analysis.
LoggingLevel.ERRORstatements are ideal to show your entire exception‘s content inside the “Catch”
In order to debug we usually write chunks of data to the debug log using System.debug statements. Will writing too many…salesforce.stackexchange.com
This is true, writing too many debug statements would affect your performance, but there’s a good solution explained in the same link, using the next approach...
System.debug(LoggingLevel.FINE, 'Write your debug ' + yourContentVar);
where “DEBUGGING” could be a Boolean value configured in a Custom Setting or Custom-Metadata. So, you can turn-off all your debugs until you need, just by changing the value of a Cust.Setting or Cust.Metadata.
Hope this helps and enjoy coding.