I was asked to touch on how to debug Salesforce apex programming, and to talk a little bit about the nature of debugging, as well as the types of problems debugging is used to solve.
Well, I can’t guide you through a start to finish debugging process with a resolution, because debugging is a very general, and reaching concept, even within the apex API and Salesforce. However, I can discuss the kind of problems that you may need to debug to solve.
Often, unhandled exception errors and addressing issues, invalid commands or parameters in function calls and other errors with complex data dumps accompanying them are hard to diagnose on their own. Looking directly through code for a time can often resolve some of the more obvious mistakes in the high level part of the programming structure, but other issues, ones not created by technically flawed programming, cannot be diagnosed this way.
For this, debugging is a common way to view what goes on during code execution, a process which, when observed after the fact, can reveal mishandled data and problematic addresses or accesses that would not be errors in static code, when the source were surveyed.
Debugging in Salesforce can be done by either looking over your Visualforce and apex programming, using the developer console available in Enterprise and Developer editions of the suite, or looking at the debug logs, which are created whenever code is directly executed in Salesforce by the developers. These logs and this console will show all processes and operations which occur during execution, which is still a lot of data, and as such, a programmer with some aptitude is needed for this kind of debugging.
However, this is the best way to sort out what kind of unhandled exceptions, misuse of data, ranges or order of execution may be going on that wouldn’t be obvious in seemingly fine code.
There is no defined procedure beyond where to look, for how to debug Salesforce apex.