Salesforce Lightning Leads Save Review the Following Error No Message

Error handling is critical to any application and should be incorporated into an app correct from the design phase. The use of well-defined fault handling patterns and best practices ensures that your app handles both expected and unexpected errors consistently and gracefully. In this weblog, nosotros'll go over some mistake handling all-time practices in Lightning Spider web Components. Since the Lightning Spider web Components framework is standards-based, most error handling best practices are based on standards besides.

Handling errors on the server side

Lightning Web Components is a UI framework that relies on the server for its data needs. The easiest way to work with Salesforce data using Lightning Web Components is to employ base Lightning components and the Lightning Data Service wire adapter. But sometimes, you need to execute custom business concern logic and employ complex transformations before returning the data to the client, and this custom logic is typically written using Apex.

Apex methods can throw a variety of exceptions. These include Query exceptions, DML exceptions and full general exceptions from business logic like parsing, type conversion, and so on. While y'all tin let Noon code send unhandled exceptions directly to the client, handling errors on the server side allows you to control what kind of errors have to be surfaced to the client vs. what kind of errors have to be handled in the backend itself.

The best way to handle errors is to wrap the logic inside a try-catch block. However, there are some kinds of errors, similar the limit exception (System.LimitException), that cannot exist handled via a catch block. Whenever throwing exceptions to the front-end, it'southward recommended that y'all create your ain custom exception classes to customize the error message and abstract the exception details that are sent to the client.

try {     // Perform logic that may throw an exception. } catch (Exception e) {     throw new CustomException(e.getMessage()); }  //Custom Exception class public form CustomException extends Exception {  }

Equally a best practice, likewise decide on a single common structure to send errors and make sure to stick to information technology beyond all backend classes. With pre-divers error types, y'all can hands make up one's mind how much item yous want to return to the client.

Treatment errors on the client side

Non all kinds of errors on the client side tin be handled the same way. In this section, we'll look at how the mistake handling mechanisms change with the origin of the fault in Lightning Web Components.

The try-catch block

Though try-catch is the almost common fashion to handle errors in code, it can exist misused. Placing all of the lawmaking inside the attempt block is not considered a best do. The code that is placed inside a try block must be based on how the error from that code is handled. If errors from dissimilar code blocks must be handled in unlike ways, employ multiple try-catch blocks. Also, the take hold of block should only handle the errors that we expect to see in information technology, the rest should exist propagated further.

Information technology'due south important to remember that the attempt-catch block can only handle exceptions in synchronous lawmaking. If an exception happens in asynchronous code execution, like in setTimeout or promises, then try-take hold of won't catch it. In the example beneath, the catch block volition not exist executed because the mistake occurs within an asynchronous process.

effort {     setTimeout(() => {         throw new Fault('some error');     }, 1000); } catch (e) {     console.fault("An error occurred"); //This will non be executed }

Errors from asynchronous operations like wire, imperative calls and promises

As mentioned before, errors from async calls cannot be defenseless by wrapping the call inside a try-catch block. In the instance of timing events similar setTimeout and setInterval , a try-catch block must be used inside the callback function to handle the errors.

setTimeout(() => {     try {         //logic     } take hold of (e) {         //handle error     } }, 300)

In the instance of wired methods, in that location are two points of potential failure. These are during value provisioning by the wire adapter and during the execution of custom logic to handle the provisioned results. Whenever there are errors with value provisioning, they're automatically stored in the error property. You tin can parse the property to know the cause of an error and handle it accordingly. If data is provisioned successfully, and you want to handle errors from the logic that handles data, place your logic inside a effort-take hold of cake as shown in the example beneath.

@wire(getContactList) wiredContacts({ error, data }) {     if (information) {         try {             //logic to handle result         } catch(e){             //error when treatment result         }     } else if (error) {         //error with value provisioning     } }

When using imperative calls or promises, you have two ways to handle the errors.

Use a catch method to handle errors that are thrown in the unabridged promise chain. Information technology includes errors from the server and errors from the logic that's written in the then method. If you don't apply the grab() block, errors from the .then block will get swallowed. As a best do, ensure all promises have a .catch statement.

getContactList()     .and then(consequence => {         //logic to handle result... dont need a attempt catch     })     .catch(mistake => {         //logic to handle errors     });

In the example in a higher place, the take hold of() method handles errors thrown in both the getContactList and the and so() block.

Employ the async/await design to telephone call the asynchronous function and wrap the lawmaking within a try-take hold of cake just similar you would a synchronous role.

async getDetails(){     try{         let result = expect getContactList();     } catch(east){         // Handle Errors     } }

Errors during the component lifecycle

Component lifecycle includes initialization of the grade and its lifecycle hooks similar constructor(), connectedCallback() and renderedCallback(). While the logic inside the lifecycle hooks can be wrapped within a try-catch block, errors when computing property values can't exist handled the same way, as shown in the instance below.

export default class PropertyInitErrorExample extends LightningElement {     sum = 10;     count = 0;     avg = sum/count; //results in an exception }

Try to avoid computing values for form fields/properties inline, and use getter methods for computation so that the logic inside the method tin exist wrapped in a try-grab block if needed.

Y'all can also use a boundary component with the errorCallback() hook to handle errors during the component lifecycle. We discuss this further in the Mistake Lifecycle and Propagation section.

Displaying and logging errors

Now that nosotros've seen how to grab different kinds of errors, let'south look at some best practices on displaying these errors in Lightning Web Components.

Understanding the fault torso payload

Before displaying an error, information technology's helpful to understand the composition of the fault object that you catch in various scenarios.

JavaScript and Web Platform APIs throw or pass up error types like ReferenceError, TypeError then on. These all inherit from the Error object which has the following properties:

name – Indicates the type of exception thrown.
message – Contains the error message.
stack – Contains the stack trace.

Here is an example code snippet and the resulting console output.

try{     undefinedVariable.toString(); } catch(east){     panel.fault(eastward);     console.fault('e.name => ' + e.name );     panel.error('eastward.message => ' + eastward.message );     panel.error('e.stack => ' + due east.stack ); }

When accessing Salesforce information using Apex or Lightning Information Service, errors are presented using a custom error object with a slightly different structure modeled subsequently the Fetch API's Response object. Here are a few properties of the custom mistake object:

ok – Specifies whether the request was successful or not.
status – Contains the HTTP condition lawmaking of the response. For example, 500 for an internal server error.
statusText – Contains the status bulletin corresponding to the status code.
trunk – The response body which varies based on the method that throws the error.

For unhandled exceptions and custom exceptions thrown by Apex, the body property holds additional details like the type of exception (body.exceptionType), the error bulletin (body.bulletin), the Apex stack trace (body.stackTrace) , and others. Here'due south an case lawmaking snippet and the resulting panel output.

//Apex Code @AuraEnabled public static Integer someMethod() {     return 10/0; }  //JavaScript Code someMethod()     .then(outcome => {         //Handle Result     })     .take hold of(fault => {         panel.mistake(mistake);     });

Errors occur in Lightning Data Service when a resources, such equally a record or an object, is inaccessible on the server or if you lot pass in an invalid input to the wire adapter (such as an invalid record Id or missing required fields) or if validation rules fail. Lightning Information Service returns a custom fault object that's very similar to what Noon returns, but the trunk property of the mistake depends on the API that returns it. It may contain a single object or an array of objects, so the logic must check for both data types when parsing it. Here's an example:

@wire(getRecord, { recordId: '$recordId', fields }) wiredRecord({error, data}) {     if (error) {         // UI API read operations render an array of objects         if (Array.isArray(mistake.body)) {             this.fault = fault.body.map(e => e.message).join(', ');         }          // UI API write operations, Apex read and write operations          // and network errors render a single object         else if (typeof fault.torso.message === 'string') {             this.error = error.body.message;         }     } else if (data) {         // Process record information     } }

As you have seen, the structure of the fault object is different in each case. Instead of repeating the logic to parse different kinds of error objects in each component, y'all tin create a unmarried function that does this and import it as a module in each component.

As a all-time practice, use the reduceErrors function from LWC Recipes (sample app which has a drove of easy-to-digest code examples for Lightning Spider web Components) to handle different kinds of error objects. This function looks for the message holding and concatenates the message if multiple message properties are establish. Here's an example of how information technology can exist used to simplify the previous code snippet.

import { reduceErrors } from 'c/utils'; ...  @wire(getRecord, { recordId: '$recordId', fields }) wiredRecord({mistake, data}) {     if (fault) {         this.errorMessage = reduceErrors(this.mistake);     } else if (data) {         // Process record information     } }

Notwithstanding, it'south important to remember that the fault body payload might be slightly unlike when dealing with third party code. The throw statement in JavaScript can throw any expression, including a number or cord. Therefore, you need to be careful when treatment exceptions from third political party code, as the approach discussed higher up might not suffice.

Displaying errors

This is perhaps the most of import office of any error handling mechanism. Errors have to be displayed in meaningful ways to the user. The most recommended way is to show the error to the user about the bespeak of failure. For case, a text field. A toast bulletin is more appropriate if the fault occurs when a push button is clicked, or if the error is related to multiple points of failure.

Base Lightning Components provide an easy and consistent mode to show error messages in forms. Base of operations Lighting Components automatically add and remove CSS classes to course controls and form itself depending on the current validation state. The reportValidity and setCustomValidity methods can be used to programmatically control error messages.

Error messages besides have to be user-friendly. Only showing that an error has occurred is not helpful. The message should indicate exactly what the error is, and what the user can practise to correct it.

To take a consistent error treatment and display mechanisms, it's a all-time practice to create a reusable component to brandish errors, and utilise it in all components. This is what nosotros did with the errorPanel component in the LWC Recipes sample app. This component also uses the reduceErrors role that nosotros discussed before to handle all formats of error objects and evidence a consequent user interface. Here's an example:

<template if:true={fault}>     <c-error-console errors={error}></c-error-console> </template>

Logging errors

Other than displaying errors to the user, y'all can also log them to the console. Equally a best practice, utilise the panel.mistake() function as it preserves the call stack in the original error bulletin and also captures the phone call stack from where the fault message is logged. This tin exist displayed past clicking on the pointer next to the message in the DevTools console.
All the console logging APIs accept multiple arguments. If more information needs to be added to the caught error, use console.error('Unexpected error during some operation', error);

Also, wherever possible, errors need to be logged to the server for better tracking and reporting purposes. This volition prove most useful when debugging issues on production. Once the awarding is in production, console.error by itself adds no value because the logged output cannot exist accessed past the developer unless explicitly shared by the end user.

Mistake lifecycle and propagation

Not all errors tin can be displayed where they originate and not all errors occur in components that accept a user interface (e.g. service component). Such errors must be propagated to a parent component to exist displayed. Unhandled errors are propagated by default through the component hierarchy.

Lightning Web Components error lifecycle

When an error occurs in lawmaking, Javascript looks for a handler that catches the error. It'southward a best practice to handle the error equally shut as possible to the origin of the error. In the case of Lightning Web Components, unhandled errors propagate from child components to parent components. If the topmost parent component doesn't handle the error, it'south thrown to the Lightning runtime.

Errors from synchronous operations are handled by the Lighting runtime past showing the "Sorry to interrupt" popup with the line number and stack trace of the fault — the error is non further propagated to the browser. In the case of errors from async operations like wire functions, promises, and so on, the error propagates to the browser and shows upwardly in the browser'due south console. The runtime too shows the error on the screen depending on the context. For example, when running a Lightning Spider web Component in Lightning Feel, async errors aren't shown in the UI. But, when running a Lightning Web Component inside a menses, the flow runtime shows the mistake at the bottom of the screen.

Propagating errors

Every bit we saw in the lifecycle in a higher place, unhandled errors propagate past default. But when using any of the error treatment mechanisms above, yous can choose to handle errors at the component level or manually propagate it further for other components to handle. Errors tin be propagated either by using the throw keyword or past using custom events. The throw keyword halts the function at the point where it'due south used, while custom events give you lot the flexibility to determine what happens afterward you fire the upshot. Errors thrown using the throw keyword tin only be handled past a component'due south parents, but using custom events gives you the flexibility to handle them using components outside the hierarchy as well.

As a best practice, propagate errors from lower level components (e.m., service components, utility functions) and handle errors in higher level components. The reason exceptions are handled at higher levels is because the lower levels don't know what the about appropriate course of activity is to handle the error.

Hither's an example that shows two variations of the same function, one that throws an error and one that fires a custom issue.

consign default form Howdy extends LightningElement {      //Using Throw keyword     divide_with_throw(a, b){         if(b == 0){             throw new Mistake('Cannot divide by 0');          }         return a/b;     }      //Using Custom Events. You tin can also use Pubsub or Lightning Message Service.     divide_with_event(a, b){         if(b == 0){             const selectedEvent = new CustomEvent('error', { particular:'Cannot divide by 0' });             this.dispatchEvent(selectedEvent);         } else {             return a/b;         }     } }

The next step would exist to handle these errors in a parent component.

If you use custom events, yous tin simply write event handlers for those events. It's of import to note that custom events aren't actual errors, then they cant be "caught" using catch blocks.
If y'all throw custom errors, you can either catch private errors using the error handling mechanisms mentioned in a higher place, or use the errorCallback() hook to capture all the unhandled and custom errors.

errorCallback() is a lifecycle hook that captures errors from all the descendent components in its tree. It captures errors that occur in the descendant's lifecycle hooks or within result handlers declared in the component's HTML template. There are a few things to think about the errorCallback() hook – It only catches errors in the handlers assigned via the template. Any programmatically assigned event handlers won't be caught. In one case an error is caught, the framework unmounts the kid component that threw the fault from the DOM. Information technology catches errors that occurs in the descendant components simply non itself.

As a best practice, create a purlieus component that implements the errorCallback() and embed your functional component inside information technology. Here is an example of a boundary component where the errors are caught using the errorCallback() hook, and displayed using the errorPanel component (which in plough uses the reduceErrors function as discussed before).

<template>     <template if:truthful={this.error}>         <c-error-console errors={this.error}></c-error-console>     </template>     <template if:false={this.error}>         <!-- YOUR COMPONENT -->      </template> </template>

import { LightningElement } from 'lwc';  consign default class Boundary extends LightningElement {     errorCallback(error, stack) {         this.fault = error;     } }

Finding the correct balance

Information technology's of import to recall that not all the errors need to be caught and handled in the component (e.g. errors in lower level components). Sometimes it's also easier to identify and fix the root cause of an mistake if it's left uncaught. This is particularly useful during the evolution and testing phase. However, information technology can exist difficult to observe the right residuum between when to catch errors and when not to catch errors, so here are a few tips:

Letting the awarding fail is always preferable to poorly treatment the errors.
Brand sure that you always gracefully handle errors when dealing with external or third party code.
Make sure that y'all always handle errors on application purlieus points like calls to the server, 3rd political party libraries, and external services.
Don't be agape to throw errors in your own code when needed.

Summary

In this blog, nosotros've seen the different means to handle errors depending on which part of the code they occur in. We've besides seen different formats of the error object and how the reduceErrors part tin can help you extract mistake messages; and how the cosmos of a boundary component tin aid safeguard your component tree from unhandled errors. Lastly, we reviewed how to propagate error letters upwards the component hierarchy using events and throw statements. You tin explore the apps in our Sample Gallery to encounter best practices in action.

For further learning, here are a few actress resources:

Exceptions in Apex
Handle Server Errors
Handle Component Errors
JavaScript Error Type
Handle Errors in Lightning Data Service

About the Author

Aditya Naag Topalli is a 13x Certified Lead Developer Evangelist at Salesforce. He focuses on Lightning Web Components, Einstein Platform Services, and integrations. He writes technical content and speaks oft at webinars and conferences effectually the world. Follow him on Twitter @adityanaag.