Establish an error-handling strategy

Dealing with errors is an important part of every application. Web applications aren’t an exception, in the contrary, they should be even better in graceful error handling, because of their huge amount of users.

We have three possible locations of caching errors in an ASP.NET application. The first one is the source of the error itself, by wrapping our code, which is likely to fail, in a try-catch block. This is a very good solution for the problem, since the error gets treated on the spot of its occurrence. You can decide to bubble the error forth, and catch it in the Page_Error event, or even further, in the Application_Error event, defined in global.asax. There’s a fourth opportunity, but it isn’t the best solution: define custom error pages in the customErrors section of your web.config. They are part of the apologize, not the solution for the problem, so you should restrict the use of them. Even worse, when you are on a custom error page, you have no way to get and deal with the error lead you there.

Before writing error-handling code, make sure that you do everything to prevent errors from happening. The best way to do so is to use a massive amount of validation. String.Empty and the Exists method should be very close friends of you.

But if the worse happened, you should fail elegantly, and without showing any inner workings of your application. Hold the detailed error messages to server administrators, and give user-friendly and meaningless errors to the everyday users. Also, you should log the exception (Health monitoring comes handy for this task).

Continue reading


Configure Debugging and Custom Errors

Configure Debugging

To debug an ASP.NET application, first you need to configure debugging. This is a process requires two steps to be taken. First, you must activate the ASP.NET debugger for your current project. To do this, right click on the project in solution explorer, and select Property Pages. In the dialog box, then select Start Options. Look for the Debuggers section in the bottom, and make sure ASP.NET is checked.

The second step is to enable debugging either for your whole application, or just different pages of it. To do so, in the compilation section of the web.config file, set debug=”true”. This causes debugging symbols to be added to your whole page. If you want to debug only some pages, you should set Debug=”true” in the @Page directive of them.

If you have the necessary rights for debugging (the application is running locally under your own user entity, or you’re an administrator) you can debug by now. If it is not the case, you should seek a way to grant yourself these rights. It’s because debugging an application needs more rights than just running it. Debugging can be harmful if not implemented carefully.

If you need to perform remote debugging then check back later, I’ll post how to do it very soon.

When you want to debug a deployed application (which is currently in production usage) you need to attach to the (possibly) remote ASP.NET worker process, and then use Visual Studio to debug it. Note that when you set a breakpoint in the application, any production user will be halted there, so be careful when using one.

When you published your web application to a production server, it is suggested that you set compilation debug to false, because it may slow down your application.

Continue reading