Recently going through the Exception handling and logging, I found an interesting topic which I would like to share.
“Exceptions”, family member to every language/technology used.These are sometimes irritating for the developers. If its 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 it is helpful for developers to resolve errors ? The answer oviously is “NO”. Here is a small tip that might be handy. Here, I am trying to detail the Use of “Custom Errors”and its attributes and elements. Web.config, the main settings and configuration for an ASP.Net web application, is the file where the custom errors find its existance. According to MSDN, custom errors elementnt provide information about custom error messages. The main motive here is to display the end user custom error pages. First, lets know how the custom error are written in the web.config(as we know in XML format):
The mode attribute of the customErrors element has three values i.e.
On:- Prevents the stack trace that is shown when exceptions arise. Also allows to display custom error pages to the end user. Custom error pagesshown to both Remote Clinets 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.
RemoteOnly:-
This is the best among all for the developers perspective, as this allows the Remote clients to view the custom error messages/pages Allows the Local users/especially developers to view the Asp.Net errors. This is the default value.
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 users.
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)
For this create user defined html pages returning customized error pages as view.
Another important thing to note is Custom Errors can be defined in two levels:- 1. Where we use customErrros described above &Application Level:-
2. Page Level:- Where we define in the Page directive i.e. for specific pages. Use of “ErrorPage” attribute is done here.
3. We also handle exceptions in Global.asax i.e. using
protected void Application_Error(Object sender, EventArgs e)
{
Exception ex = Server.GetLastError();
//self explanatory gets the most recent error
Server.ClearError();
//self explanatory clears the error (Required to clear as otherwise use gets to see the deafault ASP.Net error handlers)
Response.Redirect("");
//default redirect.
}
5. Now the precedence, that is 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
customErrors comes into action.
Note:- i) 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. ii) also if in application only one generic error page is required to show then its better to handle in Global.asax, else if as per status codes then better is customErrors in Web.config. iii) When using Handling in Global.asax, remember that the exception object needs to be retreived before the user gets redirected to custom error page. Thus if not retreived in the Global.asax, then the exception object is lost and Server.GetLastError() returns null. For better understanding :-
if Global.asax has only,
protected void Application_Error(Object sender, EventArgs e)
{
Response.Redirect("HandleException.htm"); //default redirect.
}
Now the precedence, that is 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
customErrors comes into action.
Note:- i) 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. ii) also if in application only one generic error page is required to show then its better to handle in Global.asax, else if as per status codes then better is customErrors in Web.config.
iii) When using Handling in Global.asax, remember that the exception object needs to be retreived before the user gets redirected to custom error page. Thus if not retreived in the Global.asax, then the exception object is lost and Server.GetLastError() returns null. For better understanding :-
if Global.asax has only,
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 retreive 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.
Hope this helps beginners like me.