When working with a Sitecore solution, you often integrate with other systems and work across different modules. Most enterprise-level Sitecore implementations involve complex workflows, translations, and publishing restrictions. With so many moving parts, there will inevitably be times when content items are not available as expected. These situations, whether anticipated or not, can cause components or renderings to lose access to their data sources, resulting in 500 (5xx) errors. This leads to a frustrating experience for content authors in the Experience Editor and is unacceptable for site visitors.

I had one such issue with a Sitecore Experience Accelerator (SXA) website. There have been some solutions in the past where the ExecuteRenderer processor was overridden in the mvc.renderRendering pipline. I wanted to try an approach this so that we use the processor handler, since SXA seems to be also trying to do this.

One annoying factor to this is that we have access to the Rendering in the ExecuteRenderer processor, so we can check for the datasource and rendering parameters. Kamruz questioned me saying, "How do you know if that rendering was supposed to have a datasource?". I agree, it gets complex.

Unfortunately, when we reach the handler, we do not have access to the rendering. There have been solutions documented in some blogs where you store the rendering in the context in a static variable but I did not feel it was a clean way to tackle this.

The goal was simple, let the content authors know what was wrong in an elegant way and we shouldn't affect the website user experience when one or more renderings error out.

Here goes, first, lets get a new Handler created in your project:

Once we have the handle, we need to patch our config, I prefer this to be loaded before Sitecore.XA.Foundation.Presentation.Pipelines.RenderRendering.SxaPageModeRenderingErrorStrategy.

This has helped us a lot in several situations. This also works for OOTB SXA renderings. Hope this is useful.