Kyle Kingsbury A Sitecore web development blog!

Handling Unhandled Exceptions within Sitecore Renderings

H

Even the best developers cannot stop the inevitable from happening. Whether it be a mistyped variable name within a view, an invalid content type set, or the dreaded null reference exception; errors like these and others creep up from time to time that can in some cases, bring down your Sitecore implementation. Nothing hits a developer harder than knowing their code took down the site, but i’d argue it is much, much worse for the site visitor trying to access that resource and seeing an error message.

While these types of errors cannot be avoided, it’s best to have a solution in place to mitigate the risk of having errors in your controllers or views take down a page. Luckily for us, Sitecore has improved the MVC implementation a bit since being first introduced and have exposed a series of classes that wrap the execution of all MVC renderings and provide the ability to add an ErrorStrategy upon errors. This is pretty great and given the way Sitecore typically builds things, this is super flexible and can be modified.

Nothing hits a developer harder than knowing their code took down the site, but i’d argue it is much, much worse for the site visitor trying to access that resource and seeing an error message.

Doing a little digging into the binaries with dotPeek, I notice that the default ErrorStrategy, the PageModeRenderingErrorStrategy class, will display the stack trace within the Experience Editor but allow the error to bubble up to Asp.net as an uncaught exception (if caught by Asp.net, this typically means the yellow screen of death). As I mentioned above, it’s far worse to have the site taken down from silly mistakes within your Sitecore rendering, so if the rendering fails to render it should just not render itself.

The ‘catch all’ error strategy

Let’s create a new IRendererErrorStrategy that has a few goals:

  • Be unit-testable 🙂
  • Catch all exceptions
  • Log the full stacktrace 
  • Inject HTML in place of where the rendering would have rendered on the page, but only for Experience Editor modes

As you can see from the snippet above, the main point of entry for our new ErrorStrategy is the HandleError method which gives us everything we need to handle the error. We first log the exception to Sitecore, move on to checking if we are in Experience Editor and if so writing an error block to the current TextWriter, all while being 100% unit-testable. Also note, always returning true, catches the error entirely so it cannot be bubbled up.

Registering our error strategy

Registering this strategy is fairly straightforward. We need to patch our ErrorStrategy before the default one; registering this feels clunky, so if you can find a better way to register this ErrorStrategy, let me know in the comments! 

Note: Replace the [Namespace, DLL] with your binary information.

To test out the functionality, I created an example rendering on the page (or used an existing one) and threw an exception in the view or controller rendering. And here is an example of our ErrorStrategy in Experience Editor (assumes you are using Bootstrap for styling):

Does your team follow a different approach? Let me know in the comments!

1 comment

  • Fantastic article! The only thing I would suggest is an addition of what version of Sitecore this pertains to. I was able to find it on Sitecore’s changelog, but it might help others. Good job though, good content here.

Kyle Kingsbury A Sitecore web development blog!

Recent Posts

Tags