Exception handling in Salesforce Apex: logging and managing errors  

The ability to customize your Salesforce org code greatly increases the platform’s capabilities and flexibility. However, custom code can also introduce unexpected behavior and errors that disrupt the normal flow of code execution. 

Catching and logging exceptions allows Salesforce developers to detect these issues, investigate their causes, and respond appropriately. This article explores exception handling in Lightning Components and Apex, including the use of Platform Events for reliable error logging. 

How do you handle exceptions in Salesforce Lightning Components? 

You can handle exceptions in Salesforce Lightning Components by surrounding JavaScript code with a try .. catch block. This allows you to catch and track client-side exceptions:

doSomething: function(component) { try { unexistingMethod(); // ReferenceError here } catch(e) { // log exception here } } 

It is up to you what to do with such errors. It can be JavaScript console output: 

console.error(e); 

or Lightning notification to user: 

var toastEvent = $A.get(“e.force:showToast”); toastEvent.setParams({ “title”: e.name, “message”: e.message, “mode”: “sticky”, “type”: “Error” }); toastEvent.fire(); 

In the case where some exceptions happen at a server Apex controller, we are also on a safe side through the use of a special type of exception – AuraHandledException. We can convert any exception into an AuraHandledException and send it to Lightning Component as a response:
@AuraEnabled

public static String serverMethod(String name) { try { // some Apex code } catch(DMLException ex) { throw new AuraHandledException(‘Unable to save record’); } } 

Please, note, AuraHandledException supports String argument only. This class is not extensible. If you need to send some data to client side use the following approach:

• create Apex class to hold the data.
• serialize it as JSON.
• pass it to the AuraHandledException.
• deserialize it on the client side and work with data as an object.

The strategic integration of Artificial Intelligence (AI) throughout organizational operations, with a particular focus on enhancing the capabilities of knowledge workers, holds the potential to empower institutional insurers in effectively navigating the prevailing uncertainties and addressing the escalating threats emanating within the insurtech sector. Yet despite this recognition, insurance leaders are constrained by the slow pace of progress in the industry, because of the intricate web of regulatory oversight.

Apex 

The situation with Salesforce Apex code is slightly more complicated, as exceptions can occur during code execution and require careful handling. We can set up an Apex Exception Email that will send an unhandled exception to an Administrator’s mailbox. However, in many cases this is not enough. Here are some of the disadvantages:

• Email context is not configurable. It contains an Apex stack trace, Org ID and User ID.
• Exceptions from all managed packages will be sent. There is no way to subscribe to a specific application.
• We are unable to make automatic responses in case of such exceptions.

Let’s overview the tools we can use in Salesforce to resolve it.

Rollback Of Execution Context 

Salesforce automatically commits transaction changes to the database when an execution context finishes without an unhandled exception. The System will persist changes after the execution context is finished if no unhandled exception occurs.

This approach is handy, and in most cases it is exactly what you want. But if an unhandled exception occurs, it rolls back everything, not only DML operations. Scheduled jobs, future methods, batches, queueable jobs, emails will not be run or sent. That is why the following piece of code will never work:

public void someMethod() { 
try { 
// some Apex code 
} catch(Exception ex) { 
// log exception here 
throw ex; 
// rethrow exception again 
} 
} 

By rethrowing an exception, you add an unhandled exception into the execution context. 

Should you catch all exceptions in Salesforce? 

No, you should not catch all exceptions in Salesforce. Instead, handle exceptions where they can be managed appropriately, such as at the top level of your application.

For example, you are doing a complex validation in an Apex trigger. Any call of addError() method is a DMLException. We are not interested in catching such exceptions.

The best practice is to catch exceptions in a top level component, e.g., Web service, controller of Visualforce page, server side controller of Lightning Component, etc. In other words, in any place where an execution context will start.

Adding a try .. catch block to all of your methods can ruin the readability of your code. It also increases the complexity of writing unit tests.

What is more important, by catching exceptions you are braking the logic of your application. You are forcing low level components to be responsible for decisions, e.g., what to do in a critical situation.

From time to time you can also get an exception you would never expect. For example, while your code is sending email to Contact, the following is received:

System.EmailException: INVALID_EMAIL_ADDRESS, email address has bounced 

Such things are really hard to predict, and the reason we must be able to log exceptions. 

How can you log exceptions in Salesforce Apex? 

You can log exceptions in Salesforce Apex by storing error details, such as an error message, in a custom object when an exception occurs. 

Let’s imagine we want to log an exception in a custom Apex code. For this purpose we can use a custom object to store such exceptions. Let’s say ErrorLog__c object. Look at the code below: 

public static void someMethod(String name) try { // Apex code here } catch(Exception ex) { ErrorLog__c log = new ErrorLog__c( Description__c = ‘Error: ‘ + ex.getMessage() ); insert log; } } 

This code will work if the execution context is clean, i.e., when there is no unhandled exception. However, if this code is a part in a chain of the execution context, it might not work. Look at the diagram below: 

If an exception occurs after inserting the error log record into a database, the entire transaction will be rolled back. Your ErrorLog__c record will not be saved. 

How do Platform Events improve exception logging in Salesforce? 

Platform Events provide a way to create a more reliable error logging system in Salesforce when exceptions occur.

The situation has totally changed with Platform Events. It is a new feature generally available since the Summer ’17 release (API version 40.0). Platform Event is a bus to send read only messages. When the message is sent, you are not able to return it. We will use this feature in the error logging system.

The idea is simple. When you need to save a new ErrorLog__c record, publish a Platform Event. Later, you can subscribe to this event and save the ErrorLog__c record in the database:

Please, note that the Platform Event trigger runs under the Automated Process entity. This is a system user. In order to see which user has sent the event, have a look at CreatedBy field on the Platform Event record. 

What is more important, we are not limited in logging the exception. We can react to it. For example, we can run the Apex method to repeat the failed operation as well as many more uses. 

Final thoughts 

Platform Events are a great tool for an event-driven software architecture. They extend programming functionalities in Apex and can be used even in an execution context with an unhandled exception. By implementing reliable exception logging and handling approaches, Salesforce developers can build more maintainable and resilient custom solutions. 

Need a more reliable Salesforce® solution? Connect with Avenga for expert development, integration, and implementation support. 

Rate this article!

Average 0.0 out of 5

Olena Hutak

Technology Researcher

Olena Hutak is a technology researcher covering advancements in AI, intelligent automation, and other emerging areas. She tells stories about tech that matters.