Joe Mayo: January, 2007

<< First < Previous Next > Last >>

January 27

Functional Programming in C#

The C# paradigm is shifting to something new that really isn't. Charlie Calvert interviews Anders Hejlsberg on LINQ and Functional Programming. In this interview, Anders describes upcoming changes to the C# programming language and talks in depth about a new feature called Lambda functions. Lambda's are instrumental to implementing Language Integrated Query (LINQ) functionality. They enable the language to build expression trees that represent the query you are executing. You can watch the video on Charlie's page to learn more about why and what the benefits are.

I mentioned that this is a new paradigm because C# is currently an object-oriented programming language. However, Lambda's are a functional programming concept (see also Lambda Calculus) , which enable us to program in a different way. While Lambda's are new to C#, they aren't new to programming and have been used for a long time (see The Lisp programming language).

This was a good interview and Charlie asked very relevant questions.

8:29 PM | Add a comment | Permalink | Blog it | C#

January 07

Global Exception Handling in ASP.NET

One of the most useful features I've found for Web sites is a Global Exception Handler. There are times when you can anticipate and handle exceptions in your code, which means that you can sometimes add a handler to recover from the situation. If you're a little fuzzy on C# exception handling syntax, you can review Lesson 15: Introduction to Exception Handling.

If you know that an exception from certain code is likely, you can even add code that prevents the exception from happening in the first place. For example, if there is a possibility of a file not being available, you can call File.Exists() before trying to open it. Another example would be to to the int.TryParse() method for Texbox input where a user could potentially add bad data (or even use a Validator control). These exception avoidance techniques help make your application perform better and be more user friendly.

For situations that you haven't handled, you will want to prevent cryptic error pages from appearing in front of users. Here's how to set up a global exception handler in ASP.NET:

1. Add a Global.asax file to your application if it isn't already there.

2. Add the following code to the Application_Error handler in Global.asax:

void Application_Error(object sender, EventArgs e)
{
Server.Transfer("~\\GlobalExceptionHandler.aspx");
}

3. The Server.Transfer will redirect execution to a specified page on the server. This allows you to continue processing with the same request. Next, create a Web page named "GlobalExceptionHandler.aspx". You can name it what you want, but be sure that you update the Server.Transfer call to that page.

4. Add the following code to the Page_Load method of GlobalExceptionHandler.aspx.cs:

protected void Page_Load(object sender, System.EventArgs ea)
{
    StringBuilder message = new StringBuilder("Exception occurred on Your Site:\n");

    Exception e;

    for (e = Server.GetLastError(); e != null; e = e.InnerException)
    {
        // add handling code if it makes sense

        message.Append(e.ToString());
    }

    // log, send email, and/or notify another way

    Server.ClearError();
}

5. The points to remember in the code above are that you need to call Server.GetLastError() to get the exception that was thrown and call Server.ClearError() to stop the stack unwind. If you don't call Server.ClearError(), the user will still see the Runtime Error message similar to the attached screen.

Sometimes exceptions are chained, which is why I pull the InnerException on each iteration of the for loop. This ensures that anyone trying to figure out the problem will have the full story, which can often be masked by a top-level exception that is vague and meaningless. You'll have to decide whether handler code, such as an if or switch statment that evaluates exception types would make sense for your application. I do some specific handling sometimes, depending on the needs of the application.

One thing you should always do is record the exception somehow. You have many options for logging, including event log, tracing, Logging Application Blocks, and 3rd party logging solutions. I also like to send emails to a designated address so that someone can find and fix the problem as soon as possible. Other options could include WMI or something similar to notify monitoring software about a potential problem.

6. Add a message to the Web page of your global exception handler to communicate with the user. I often let the user know that there was a problem and someone has been notified, which is a bit more comforting to them than seeing a Runtime Error message.

Regardless of your specific strategy of managing exceptions, I recommend that you set up a global exception handler. It will make your application more robust and enable you to provide a more comfortable user experience.