While you are developing the application, the code editor catches most syntax errors. However, the errors that cannot be caught during application development cause the application to display error messages at run time. The errors that occur while the application is running are called run-time errors.
On the other hand, if there is a problem in the programming logic, the application would run without errors, but it will not provide the desired functionality. Such errors are called logical errors. The process of going through the code to identify the root cause of an error in an application is called debugging.
Error Handling
ASP.NET provides rich support for handling and tracking errors that might occur while applications are running. When you run an ASP.NET application, if an error occurs on a server, an HTML error page is generated and displayed in the browser. While displaying error messages to users, ASP.NET takes care of the security issues by default, which makes it a reliable development tool for Web applications. ASP.NET ensures that no secure information, such as the remote machine compiler messages, configuration settings, filenames, stack traces, or source code, is revealed on the client machine. When an error occurs, a generic error message, "Application Error Occurred," is displayed to users. To see the error details, one of the following needs to be done:
In this code, the tag has an attribute mode whose value is set to "Off". This value indicates that the remote users always see the original error message that is generated on the server.
Using custom error pages
As mentioned earlier, an HTML error page is displayed to a user in case an error occurs on a server. These error messages are secure, because they do not leak any secret information. However, these pages are not pretty to see. You can create custom error pages that can be displayed in case errors occur. For example, you can create an error page that displays the company's brand and some error messages that you want to display. To implement the custom error pages:
1. Create a Web page that you want to display as an error message page. This can be a page with an .html or .aspx extension.
2. Modify the Web.config file of your application to point to the custom page in the event of any error. The configuration settings, shown here, point to a file called MyError.aspx:
The mode attribute of the tag can take three values:
On: Indicates that the custom error messages are always sent to users and that the detailed ASP.NET error page is never shown.
Off: Indicates that only original error messages are sent to users even if a custom error page is available.
RemoteOnly: Indicates that the custom error messages are displayed only to remote users accessing the site. If no custom error page is available, remote users simply see a message indicating that an error has occurred.
When you modify the Web.config file to set the defaultRedirect attribute, the user is directed to the same custom error message irrespective of the type of the error. The type of the error is identified by the HTTP status code.
In addition to displaying error messages to users, you should ensure that the administrators and developers are also able to track errors. This would allow them to identify and solve the problems associated with the code.
You can implement error tracking by handling the Application_Error event, an application-level event that is generated when an exception occurs during the processing of a Web request. The developers can use this event handler to obtain information, such as the page URL, the query string arguments, and cookie values.
With this information, developers can write the code to track the problem or notify administrators and developers about the problem. The errors can be tracked by using the Event Log, sending e-mail to administrators, or writing to a database etc.
You can write to the NT Event Log by adding code in the Application_Error event handler in the Global.asax file of your application. You can write to the NT Event Log only after you've imported the System.Diagnostics namespace.
To implement error tracking, create a Visual Basic ASP.NET Web Application project. In this project, import the System.Diagnostics namespace in the Global.asax file:
Imports System.Diagnostics
RELATED POST
CREATING ASSEMBLIES WITH ASP.NET
BUILDING HANDLERS IN ASP.NET
INTERFACES AND CLASSES CREATION IN ASP.NET
CACHING IN ASP.NET
CACHING IN ASP.NET PART TWO
WIRE LESS APPLICATION WITH ASP.NET
SECURITY IN ASP.NET PART ONE
SECURITY IN ASP.NET PART TWO
LOCALIZING ASP.NET APPLICATIONS
DEPLOYING ASP.NET APPLICATIONS
ASP.NET CONFIGURATION SYSTEM
WEB SERVICES IN ASP.NET
WEB SERVICES PART TWO
WEB SERVICE INFRASTRUCTURE
WEB SERVICE INFRASTRUCTURE PART TWO
EXCHANGING MESSAGES IN ASP.NET
MICROSOFT HAIL STORM
SOAP AND DOT NET PART ONE
SOAP AND DOT NET PART TWO
On the other hand, if there is a problem in the programming logic, the application would run without errors, but it will not provide the desired functionality. Such errors are called logical errors. The process of going through the code to identify the root cause of an error in an application is called debugging.
Error Handling
ASP.NET provides rich support for handling and tracking errors that might occur while applications are running. When you run an ASP.NET application, if an error occurs on a server, an HTML error page is generated and displayed in the browser. While displaying error messages to users, ASP.NET takes care of the security issues by default, which makes it a reliable development tool for Web applications. ASP.NET ensures that no secure information, such as the remote machine compiler messages, configuration settings, filenames, stack traces, or source code, is revealed on the client machine. When an error occurs, a generic error message, "Application Error Occurred," is displayed to users. To see the error details, one of the following needs to be done:
- Access the page again from the local server.
- Modify the configuration settings of the computer.
- Modify the configuration settings of the application's Web.config file to enable remote access.
Using custom error pages
As mentioned earlier, an HTML error page is displayed to a user in case an error occurs on a server. These error messages are secure, because they do not leak any secret information. However, these pages are not pretty to see. You can create custom error pages that can be displayed in case errors occur. For example, you can create an error page that displays the company's brand and some error messages that you want to display. To implement the custom error pages:
1. Create a Web page that you want to display as an error message page. This can be a page with an .html or .aspx extension.
2. Modify the Web.config file of your application to point to the custom page in the event of any error. The configuration settings, shown here, point to a file called MyError.aspx:
The mode attribute of the
On: Indicates that the custom error messages are always sent to users and that the detailed ASP.NET error page is never shown.
Off: Indicates that only original error messages are sent to users even if a custom error page is available.
RemoteOnly: Indicates that the custom error messages are displayed only to remote users accessing the site. If no custom error page is available, remote users simply see a message indicating that an error has occurred.
When you modify the Web.config file to set the defaultRedirect attribute, the user is directed to the same custom error message irrespective of the type of the error. The type of the error is identified by the HTTP status code.
In addition to displaying error messages to users, you should ensure that the administrators and developers are also able to track errors. This would allow them to identify and solve the problems associated with the code.
You can implement error tracking by handling the Application_Error event, an application-level event that is generated when an exception occurs during the processing of a Web request. The developers can use this event handler to obtain information, such as the page URL, the query string arguments, and cookie values.
With this information, developers can write the code to track the problem or notify administrators and developers about the problem. The errors can be tracked by using the Event Log, sending e-mail to administrators, or writing to a database etc.
You can write to the NT Event Log by adding code in the Application_Error event handler in the Global.asax file of your application. You can write to the NT Event Log only after you've imported the System.Diagnostics namespace.
To implement error tracking, create a Visual Basic ASP.NET Web Application project. In this project, import the System.Diagnostics namespace in the Global.asax file:
Imports System.Diagnostics
RELATED POST
BUILDING HANDLERS IN ASP.NET
INTERFACES AND CLASSES CREATION IN ASP.NET
CACHING IN ASP.NET
CACHING IN ASP.NET PART TWO
WIRE LESS APPLICATION WITH ASP.NET
SECURITY IN ASP.NET PART ONE
SECURITY IN ASP.NET PART TWO
LOCALIZING ASP.NET APPLICATIONS
DEPLOYING ASP.NET APPLICATIONS
ASP.NET CONFIGURATION SYSTEM
WEB SERVICES IN ASP.NET
WEB SERVICES PART TWO
WEB SERVICE INFRASTRUCTURE
WEB SERVICE INFRASTRUCTURE PART TWO
EXCHANGING MESSAGES IN ASP.NET
MICROSOFT HAIL STORM
SOAP AND DOT NET PART ONE
SOAP AND DOT NET PART TWO
No comments:
Post a Comment