Global Office Directory
More Products
Share this page
Home > Community > Technical Blogs > John West Sitecore Blog > Trap Sublayout Exceptions in the Sitecore ASP.NET CMS
This blog post describes how you can manage exceptions from sublayouts in the same way that the Sitecore ASP.NET CMS handles exceptions in XSL renderings.
Since writing the blog post Custom Caching Criteria with the Sitecore ASP.NET CMS, I seem to find more and more value in the technique described. For example, the Presentation Component API Cookbook on the Sitecore Developer Network (SDN) forums describes how to manage exceptions in XSL renderings, web controls, layouts, and the application, but doesn't mention exceptions in sublayouts. You can override the Sublayout control to manage exceptions in sublayouts, but you will have to read that prior post for more information.
Unfortunately, it seems that you have to override each method that can throw an exception. I think this is just an aspect of the ASP.NET framework that you have to deal with - I don't see what Sitecore could do about it other than override every lifecycle method for you with a try/catch block, which I would consider bad practice. You should probably only override the methods that you know you need to use.
To trap exceptions in sublayouts, you can implement a solution based on this prototype. The most important method to override is DoRender(). Basically, create an HtmlTextWriter, open a try block, pass that HtmlTextWriter to the DoRender() method in the base class, and if that method call generates no exception, flush the HtmlTextWriter to the output stream. This should prevent Sitecore from writing any output from the sublayout to the output stream in case of exception (I assume that otherwise ASP.NET could somehow write half of the output before hitting the exception). In the catch block, do whatever you want to do with the error, such as generate no output, redirect or generate the kind of output Sitecore generates for XSL renderings depending on the customErrors element in the web.config file.
In general, it's best to use local try/catch blocks and only trap exceptions that you can handle. For example, a sublayout probably can't handle a disk outage, and hence should let ASP.NET terminate processing of the page by bubbling that exception up to the page level. But there might be cases where you do want to handle exceptions in sublayouts, especially non-critical sublayouts that depend on components that throw exceptions due to non-critical conditions. Maybe you get this sublayout from a vendor and you can't add try/catch blocks to the code. So I created the DisableErrorManagement parameter that allows you to disable exception management for an individual sublayout (which might be the opposite of what you need).
I used the ErrorHelper class from the Presentation Component API Cookbook, but I changed it to a static class. Somehow the exception and stack trace appears in the Sitecore log, although I never explicitly call any logging methods. There are certain errors that appear harder to catch, such as parsing the .ascx (for example, if it inherits from a class that does not exist). Hopefully you find those conditions in development.
Of course you could take a similar approach and override the XslFile class to trap exceptions, but that also gets a little more complex, as the default XslFile control already traps exceptions. Maybe it's better to use an error control as described in the Presentation Component API Cookbook. I probably could have used an error control for sublayouts as well, but at 46 lines, I find the existing prototype quite succinct.
Like everything I blog about, I wrote this code, but didn't really test it, so use it at your own risk.
Tags: API, Architecture, Infrastructure
John has over ten years of experience in the CMS industry. His areas of focus include the Sitecore community, Web industry research, Sitecore technical documentation, and product management.
This website is designed to be fully functional with scripts disabled in browser. Please contact the webmaster for any suggestions