Implementation of exception Management in asp.net 2.0

Introduced

In any application system development, exception management is a key area for developers. As a developer, you should adopt an appropriate exception management strategy that allows you to write robust and high-quality code. If used properly, exception management will be a powerful concept and make your development work easier. However, an improper exception handling will degrade the performance of your application system.

Before you delve into these, it's important to figure out what exception management is. In general, exceptions mean "break the system's predetermined assumptions". "Exceptions" and "errors" are not the same, for the sake of clarity, let's look at two examples:

Example One

We assume that you are trying to write data to a file, and your application thinks the file is on the correct path. If not, an exception is thrown. And then again, if your job is to keep track of this file, then there's an exception to the code (which cannot find the file) that would be a bad coding habit, and it should be handled by the validation code (not the exception).

Example Two

Let's assume that in a general ASP.net program, you are trying to update all the required fields in the database. Your application considers this database connection to be available, assuming that the connection is actually unavailable ... Throwing an exception is a solution. And we have to say again, if there are several fields with blank values when you update the required fields for the database, it is not necessary to throw an exception, which should be done by the validation code.

How to handle exceptions

As a developer, you should feel the benefits of building a structured exception handling mechanism through try, catch, finally blocks. NET Framework provides a large stack of exception handling levels to handle different kinds of exceptions. All exceptions are inherited from the exception (base class). You can use inheritance to implement custom error handling to extend the exception handling mechanism. Unfortunately, many developers misuse this architectural capability. One thing to remember is when an exception occurs at run time (the architecture) how should it work? In general, there are three kinds of situations:

Ignore the exception and let it rise in the call stack and be caught by another catch block.

Catch the exception and perform the necessary actions for your application, if you do not want to throw an exception again in the exception.

Catch the exception and overwrite it with other exceptions. This is more closely related to your application. Exception overrides are designed to avoid breaking the abstraction level (in the schema). You can specify what the original exception is by the InnerException attribute of the exception you throw, so that you can overwrite the existing exception with a new exception (more relevant to your system). To understand the exception overlay, let's look at a method that can cause ioexception anomalies, and you can use Loadingexception or failtoloadinfoexception at the application level to overwrite the original IOException exception. This is better than putting the ioexception on the ground to the user.

The exception handling framework for an application should have the following (requirements):

detecting anomalies;

Execute code cleanup;

Internal exception coverage;

Internal exception replacement;

Record and report error messages;

Establish events that can be externally monitored to help the system operate;

At the beginning you should build a consistent, robust exception management architecture that encapsulates and abstracts the details of its records and reports in all of your systems.