How and where to handle exceptions in a three-tier web application? In particular, Sql database exceptions

Question

I am creating a standard three-tier ASP.NET web application, but I'm afraid of where to do certain things - especially for exception handling.

I tried looking at the websites for some examples, but I can not find a single one that goes up to the whole project showing how everything is connected.

In my data layer, I connect to SQL Server and do some things. I know that I need to catch exceptions that may be raised as a result, but I do not know where to do this.

From what I read, I have to do it at the UI level, but in this case I'm not sure how to ensure that the connection to the database is closed. Can anyone clarify how to do this? Also, if anyone knows where I could find an approximate three-tier web application that follows best practices that will also be good.

thanks

Answer 1

There are no simple answers or templates that will ensure success. Like your verification strategy, your specific exception handling strategy depends on your specific situation and is often a compromise between time and completeness. There are some helpful tips we can give:

• Never hide a stack trace; never use "Rethrow" unless for security reasons you want to hide what happened.
• Don't feel like you need error handling everywhere. By default, in your lower tiers, so that the actual error leaks to the upper level, not bad. UI / Controller is where you really need to decide how to react to something wrong.
• At every point like you, what exactly do you want if something goes wrong. Often you can’t come up with anything better than just letting it go to the top level or even to the client machine. (although in the process of creating detailed reports.) If so, just let it go.
• Make sure you delete unmanaged resources (anything that implements IDisposable.) Your data access is a great example. Either ( A ) Call .Dispose () for your (especially) connection, command, datareader, etc. In the Finally or ( B ) block, use Using syntax / template , which guarantees the correct deletion.
• Look for places where errors are likely, and where you can look for specific errors, respond (by retrying, waiting for retrying again, trying this action differently, etc.), and then hopefully succeed. Most of your exception handling is success, not just crash reporting.
• In the data layer, you must consider what to do if something goes wrong in the middle of a multi-stage process. You can allow the actual error to be carried over, but this level should handle things after the error. Sometimes you want to use transactions.
• In an asynchronous situation (or (A.) due to multiple threads or (B.), because the business logic is separately processed on the “target machines” and so on and acts later), in particular, you need to have a plan for the error logging.
• I would rather see “error handling code” in 25% of your application than 100%. 100% means that you probably wanted it to look and feel that you have error handling. 25% means you spent time handling exceptions, where they really needed to be handled.

Answer 2

Just a side point that can control your thinking: if you have any type of volume that can lead to concurrency (deadlocks) problems, you want your application to detect this particular SQL error and retry the operation (e.g. transaction) This indicates to handle some exceptions at the data or business level.

-Krip

Answer 3

I consider it my best practice to handle exceptions at the last crucial moment. This usually means the UI level (i.e., the Controller in an MVC application or in code in a traditional asp.net application). At this high level, your code “knows” what the user is asking, and what to do if something doesn’t work.

The exception handling below in the call stack usually results in the call code not being able to handle the exception correctly.

At your data level, you should use standard templates (e.g. using statement for IDisposables such as SqlConnection) that you know might happen (don't do this due to out of memory or other rare cases) and then let them flow the call stack when they do it. In most cases, you might want to catch these exceptions and wrap them in one type of exception, in situations where MANY exceptions can be handled by callers.

If you need to “clear” the material before allowing exceptions, you can always use finally block to clear. You do not need to catch using the finally block.

I do not know any examples of small sites that are designed to highlight the proper handling of exceptions, sorry.

Answer 4

This is not a specific answer to your question, but if you are interested in best practices, I would consider Microsoft Patterns and Practices:

Application Architecture Guide

Web Application Guides