Global Office Directory
More Products
Share this page
Home > Community > Technical Blogs > John West Sitecore Blog > Update: Trap Sublayout Exceptions in the Sitecore ASP.NET CMS
The Unhandled exceptions in user controls - alternative behaviour? thread on the Sitecore Developer Network (SDN) forums prompted me to write this update to my existing blog post Trap Sublayout Exceptions in the Sitecore ASP.NET CMS, which explains how you can manage exceptions in sublayouts using the Sitecore ASP.NET CMS. I highly recommend that you read that blog post first, as well as the Custom Caching Criteria with the Sitecore ASP.NET CMS post to which it refers.
In the Unhandled exceptions in user controls - alternative behaviour? forum thread, Paul George mentions that cache criteria apply to the rendering even if an exception occurs. This makes sense, as the solution hides the exception from the system. In many cases, that might be exactly what you want - don't keep throwing the same exception, but cache the fact that it occurred. In other cases you may want the presentation component to retry the operation.
But I think Paul may have been wrong, because Sitecore does include some logic to prevent caching components that experience exceptions. My conclusion is that Paul had removed the call to the RenderError() method of the Sitecore.Web.UI.WebControl class, which sets a property that indicates that the control experienced an error, or maybe the /configuration/system.web/customErrors section of the web.config file was not generating the results he expected. In any case, the issue warrants further explanation.
Sitecore uses the Sitecore.Web.UI.WebControl base class for all presentation component types. Sublayouts are technically .aspx files that inherit from System.Web.UI.UserControl rather than Sitecore.Web.UI.WebControl, but Sitecore binds them to the control tree using the Sitecore.Web.UI.WebControls.Sublayout class, which does inherit from Sitecore.Web.UI.WebControl. The Sitecore.Web.UI.WebControls.XslFile class used for XSL renderings also inherits from Sitecore.Web.UI.WebControl, as should any web controls that you implement. The error management features that Sitecore provides apply to sublayouts, web controls and XSL renderings, although you might configure and implement each differently. For information about how to change the classes used for sublayouts and web controls, see my blog post Custom Caching Criteria with the Sitecore ASP.NET CMS.
The Sitecore.Web.UI.WebControl maintains a flag internally to indicate whether the component experienced an error. To set the flag, you need to call the RenderError() method of the control. The RenderError() method invokes the error control to render information about the error, sets the flag, and then logs the error. For more information about the error control, see the Presentation Component API Cookbook on SDN (and see the /App_Config/prototypes.config file).
You can implement a solution based on this untested prototype that hides all errors.
If you want to cache the fact that the error occurred, then don't call the RenderError() method.
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