quote:Originally posted by tectrix
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.