In this section, we will review the needs/concerns of the execution context and how each can lead to a common requirement of the application business logic. This helps define the guidelines around writing the application business logic, thus making it logical and more reusable throughout the platform and application:

• Error handling: When it comes to communicating errors, traditionally, a developer has two options: let the error be caught by the execution context or catch the exception to display it in some form. In the Visualforce Apex Controller context, it's typical to catch exceptions and route these through the ApexPage.addMessage method to display messages to the user via the apex:pageMessages tag. In the Lightning Component Apex Controller context, it's recommended to catch exceptions and re-throw them as AuraHandledException. In the Batch Apex context, letting the platform know that the job has failed involves allowing the platform to catch and handle the exception instead of your code. If you want to track these errors yourself, you can subscribe to the platform event called BatchApexErrorEvent. For Apex REST classes, unhandled exceptions will automatically output exceptions in the REST response:
  • Application business code implication: The point here is that there are different concerns with regard to error handling within each execution context. Thus, it is important for application business logic not to dictate how errors should be handled by calling the code.
• Transaction management: As we saw earlier in this chapter, the platform manages a single default transaction around the execution context. This is important to consider with the error-handling concern, particularly if errors are caught, as the platform will commit any records written to the database prior to the exception occurring, which may not be desirable and may be hard to track down:
  • Application business code implication: Understanding the scope of the transaction is important, especially when it comes to writing application business logic that throws exceptions. Callers, especially those catching exceptions, should not have to worry about creating Database.Savepoint to rollback the state of the database if an exception is thrown.
• Number of records: Some contexts deal with a single database record, such as a Visualforce standard controller, and others deal with multiple records, such as Visualforce standard set controllers or Batch Apex. Regardless of the type of execution context, the platform itself imposes governors around the database operations that are linked with the number of records being processed. Every execution context expects code to be bulkified (minimal queries and DML statements).
  • Application business code implication: Though some execution contexts appear to only deal with a single record at a time in reality because database-related governors apply to all execution context types, it is good practice to assume that the application code should consider bulkification regardless. This also helps make the application code more reusable in future from different contexts.
• State management: Execution contexts on the Lightning Platform are generally stateless; although, as described earlier in this chapter, there are some platform facilities to store state across execution contexts:
  • Application business code implications: As state management solutions are not always available and are also implemented in different ways, the application code should not attempt to deal directly with this concern and should make itself stateless in nature (the use of Platform Cache in order to improve performance is the exception to this rule). If needed, provide custom Apex types that can be used to exchange the state with the calling execution context code, for example, a controller class.
• Security: It could be said that the execution context should be the one concerned with enforcing this, as it is the closest to the end user. This is certainly the case with a controller execution context where Salesforce recommends the with sharing keyword is placed. However, when it comes to CRUD and FLS security, the practicality of placing enforcement at the execution context entry point will become harder from a maintenance perspective, as the code checking the user permissions will have to be continually maintained (and potentially repeated) along with the needs of the underlying application business code:
  • Application business code implication: The implication here is that it is the concern of both the execution context and the application business logic to enforce the user permissions. However, in the case of sharing, it is mainly that the initial Apex caller should be respected. As we dive deeper into the engineering application business logic in later chapters, we will revisit security several times.