Thank you so much Lee Dumond!
You even cleared up the things that were in my head but I couldn't write them up in the post...
Could you please clear me one more thing? If we hook up this kind of "Exception Handling"(Exception Handling in DAL & BLL, the one you specified),don't we have to then configure the Health Monitoring System which ASP.NET 2.0 provides?

Not really. I will say that Health Monitoring in ASP.NET is a good thing to have. It provides a convenient way of persisting error data, and a lot of nice built-in functions, like logging heartbeats, failure audits (invalid login attempts, etc) custom events (like the delete records event in the book), and other stuff. No sense re-inventing the wheel if we already have a system like this in place.

But you could also write your own error-logging logic if you wanted. A good place to do that is in Global.asax. For real simple sites, I sometimes won't even log errors, instead, I'll just have the app send the webmaster an email about the error.

So yes, health monitoring is useful, but it's important to understand that error monitoring, logging and notification isn't the whole story. Trapping exceptions and presenting useful feedback to your users when they happen is the most important thing.

I will also add this -- and this is something a lot of people don't realize -- not every exception is an "error" in the classic sense. It is sometimes useful to throw your own exceptions that wouldn't necessarily be considered "errors" by ASP.NET, but would be violations of your own logic. Like say, for example, you have an scheduling application where someone tries to schedule an appointment for a date in the past. You could throw an ApplicationException in this case, or even your own custom exception that derives from ApplicationException, like MyAppointmentDateException. Then, you can handle it as required.

Thanks Lee Dumond, for this complete explanation. You explain very well. When I read ur replies I feel as if I’m reading some book’s article :P
Okay, I’ve this code in my Global.asax to send error details to me . I got this code from some online article and it works fine. Does it hurt if I use this along with Health Monitoring System or should I configure SimpleMailWebEventProvider with SqlWebEventProvider if I want errors/events details be send to me along with being logged in the DB?
void Application_Error(object sender, EventArgs e)
    {
        string strError = "Error in: " + Request.Path +
            "\nUrl: " + Request.RawUrl + "\n\n";

        // Get the exception object for the last error message that occured.
        Exception ErrorInfo = Server.GetLastError().GetBaseException();
        strError += "Error Message: " + ErrorInfo.Message +
            "\nError Source: " + ErrorInfo.Source +
            "\nError Target Site: " + ErrorInfo.TargetSite +
            "\n\nQueryString Data:\n-----------------\n";

        // Gathering QueryString information
        for (int i = 0; i < Context.Request.QueryString.Count; i++)
            strError += Context.Request.QueryString.Keys[i] + ":\t\t" + Context.Request.QueryString[i] + "\n";
        strError += "\nPost Data:\n----------\n";

        // Gathering Post Data information
        for (int i = 0; i < Context.Request.Form.Count; i++)
            strError += Context.Request.Form.Keys[i] + ":\t\t" + Context.Request.Form[i] + "\n";
        strError += "\n";

        if (User.Identity.IsAuthenticated) strError += "User:\t\t" + User.Identity.Name + "\n\n";

        strError += "Exception Stack Trace:\n----------------------\n" + Server.GetLastError().StackTrace +
            "\n\nServer Variables:\n-----------------\n";

        // Gathering Server Variables information
        for (int i = 0; i < Context.Request.ServerVariables.Count; i++)
            strError += Context.Request.ServerVariables.Keys[i] + ":\t\t" + Context.Request.ServerVariables[i] + "\n";
        strError += "\n";

        // Sending error message to administration via e-mail
        System.Web.Mail.SmtpMail.Send("[email protected]"," [email protected]", "Error has occured", strError);



    }

It doesn't hurt at all. However, it would be a bit redundant if you were using SimpleMailWebEventProvider to send errors, along with handling the app-level event in Global.asax. Of course, you could configure SimpleMailWebEventProvider to NOT send errors, but to send other stuff, like Audits, Custom Events, and so on; and rely on Application_Error to send the errors.

The advantage of using Global.asax is that it is easier to customize exactly what info you want included in the email, and to format it the way you want. The advantage of using SimpleMailWebEventProvider is that it can notify you of other HM events besides errors, and it's easier to specify exactly what kind of events/errors you want to be notified about and under what conditions.

Thanks Lee Dumond! You really healped me clearing my concept about handling and managing Exceptions and Events. Thanks once again.

You need to be careful with Application_Error. It can catch exceptions that occur in various places where some of those objects (in the code above) may be null and you can get further exceptions that prevent the email from being sent. If you use this type of code you should do a lot of checking for nulls also. For example:

Well, thanks for pointing this out. I didn't think of this.

bear in mind that throwing exceptions is expensive. they are best handled in the method in which they occur and an appropriate value/message passed back to the caller.