Custom Errors in ASP.NET

When the yellow screen of death appears, users get distracted!! Throw them at a beautiful & different Page… let’s learn…

Introduction

Recently, while going through the Exception handling and logging, I found an interesting topic which I would like to share – “Exceptions“, which is a family member to every language/technology used. These are sometimes irritating for the developers. If it’s irritating for developers, what would be the condition of the end user when he/she views the “yellow screen populated with God knows what!“.

Now the question arises, should they be displayed with that entire stack trace that is sometimes helpful for developers to resolve errors? The answer obviously is “NO”.

Here is a small tip that might be handy. Here, I am trying to detail the Use of “Custom Errors“and its attributesand elements. Web.config, the main settings and configuration for an ASP.NET web application, is the file where the custom errors find its existence.

According to MSDN, custom errors elements provide information about custom error messages. The main motive here is to display the end user custom error pages. First, let’s know how the custom errors are written in the web.config (as we know in XML format):

 

The Modes Used

On

• Prevents the stack trace that is shown when exceptions arise
• Also allows to display custom error pages to the end user
• Custom error pages shown to both Remote Clients as well as Local

Off

• Makes the end user view the description of the exception along with the entire stack trace.
• ASP.NET error/exception and stack trace shown to both Remote clients and Local as well.

Remote Only

• This is the best among all for the developers’ perspective, as this allows the Remote clients to view thecustom error messages/pages.
• Allows the Local users/especially developers to view the ASP.NET errors.
• This is the default value.

Some More Facts

Another attribute that is used is “defaultRedirect“. This is an optional attribute that is used to redirect the browser to the default error page if any, else generic errors are shown to the users.

 

• This is the best amongst all from the developers’ perspective, as this allows the Remote clients to view thecustom error messages/pages.
• Allows the Local users/especially developers to view the ASP.NET errors.
• This is the default value.
• There are also child elements used inside the scope of the customErrors. The one which I have used and came across is the error element. This might be handy if there is a requirement to show specific error pages for specific HttpStatusCodes(401,404,500).

Another important thing to note is Custom Errors can be defined in two levels:

• Application Level: Where we use customErrros described above &
• Page Level: Where we define in the Page directive, i.e., for specific pages. Use of “ErrorPage” attribute is done here.

We also handle exceptions in Global.asax, i.e. using:

Now the precedence, that is:

Quote:

When all are defined, then Page level will have higher precedence that global.asax and customErrors. And if the customErrors are also defined along with in Global.asax, then customErrors will have no effect and if no exception handling is done in the global.asax, then Web.config that is customErrorscome into action.

Points of Interest

Note

• Flexibility is more in Global.asax as we can redirect the user anywhere we want and also we can log the exceptions into DB/azure blobs writing codes on the server side.
• Also, if in application, only one generic error page is required to show, then it’s better to handle inGlobal.asax, else if as per status codes then better is customErrors in Web.config.
• When using Handling in Global.asax, remember that the exception object needs to be retrieved before the user gets redirected to custom error page. Thus if not retrieved in the Global.asax, then the exception object is lost and Server.GetLastError() returns null.
• For better understanding: If Global.asax has only:
  
  C#

  protected void Application_Error(Object sender, EventArgs e) { Response.Redirect("HandleException.htm"); //default redirect. }

  1 2 3 4

  protected void Application_Error(Object sender, EventArgs e) {     Response.Redirect("HandleException.htm"); //default redirect. }

  
  & in the ErrorController.cs and here in the method, we try to retrieve the error object, then we get null.
• The reason behind this is the flow. When the exception occurs, it tries to be handled in global.asax Application_Error method (above written method) that only redirects the user to Error/HandleException & the user lands here on redirection only because of the error, thus the error is lost once user gets redirected.

Here, I end this. Thanks for reading. Hope you learnt something from this.

References:

DotNet Tricks