HttpContext.IsCustomErrorEnabled - One of ASP.NET's hidden gems
Calling a property a gem might be a bit of an exaggeration, but this particular property is still rather valuable. In many situations a developer wants to enable a feature or part of a feature only for debugging and testing purposes. The IsCustomErrorEnabled property combines three values to tell you whether custom errors are enabled for a particular request. This isn't as simple as reading the web.config file to check the <customErrors> section. There's a bit more going on behind the scenes to truly determine whether custom errors are enabled.
The property looks at these three values:
- The web.config's <deployment> section's retail property. This is a useful property to set when deploying your application to a production server. This overrides any other settings for custom errors.
- The web.config's <customErrors> section's mode property. This setting indicates whether custom errors are enabled at all, and if so whether they are enabled only for remote requests.
- The HttpRequest object's IsLocal property. If custom errors are enabled only for remote requests, you need to know whether the request is from a remote computer.
The property is used in several places in ASP.NET to determine what type of error message to display to the user. When custom errors are enabled, the error messages tend to be terse so as not to disclose any secret information. When custom errors are disabled, more extensive information is displayed to the user including stack traces, type names, and file paths. One of the nice things about this property is that it works in all trust levels (well, at least Medium trust and higher - I'm not sure about Low and Minimal). It's also nice that you don't have to worry about reading from web.config manually.
Just recently in ASP.NET MVC we added a feature where we used this property to determine whether to show a generic error message such as "Your site is broken!" instead of full stack traces and debugging information. I hope this property ends up getting called by your ASP.NET applications and controls!