Help me - I’m a user.

I need help. I’m a user - I admit it. I love using the using statement in C# (I’m not talking about the one that’s equivalent to the #include statement). Imagine my surprise that some people haven’t heard of this wonderful, wonderful keyword.

So what does it actually do? Well, you can think of it as automatically calling Dispose on a disposable object. Effectively, it translates into a try/finally block where Dispose is called automatically in the finally section. So:

using (SqlConnection conn = new SqlConnection())
{
 // Do something...
}

translates into

SqlConnection conn = null;
try
{
  conn = new SqlConnection();
  // Do something..
}
finally
{
  if (conn != null && conn is IDisposable)
    ((IDisposable)conn).Dispose();
 
}

It’s perfectly possible to nest using blocks, and the compiler will ensure that Dispose is called in the correct fashion. So, if a class has a Dispose method, you should really consider wrapping it in a using(…) block.

Warning - If the class you are referencing in the using statement doesn’t implement IDisposable then you can’t do this.

Now, did you know that you can alias namespaces in a using statement? It’s true - if you don’t want to put in that StreamWriter is in the System.IO namespace all over your code and you are in the midst of classname conflicts, it’s a simple matter to put something like the following in your code:

using io = System.IO;

Then, elsewhere in your code you can use:

using (io.StreamWriter sw = new io.StreamWriter(@"c:\dev.txt"))
{
}

Note the “clever” use of the two different using types.

Returning status 500 from an HttpHandler

Recently, on The Code Project, a question was posted about returning the status 500 and it not actually working. I suggested that an HttpHandler would be the way to cope with this, and the original poster asked how to do this. Rather than posting the answer there, I decided to post it here. Without further ado, this is how it is done:

/// <summary>
/// Base class for ensuring that the handler always returns
/// a status code.
/// </summary>
public abstract class StatusHandlerBase : IHttpHandler
{
  private int _returnStatus = 400;
  /// <summary>
  /// Initializes a new instance of <see cref="StatusHandlerBase" />.
  /// </summary>
  public StatusHandlerBase() {}
  /// <summary>
  /// Initializes a new instance of <see cref="StatusHandlerBase" />.
  /// </summary>
  /// <param ref="status">The Http status code</param>
  public StatusHandlerBase(int status)
  {
    _returnStatus = status;
  }
  /// <summary>
  /// Don't let the response be cached by the browser. Set up the status code
  /// and return.
  /// </summary>
  public virtual void ProcessRequest(HttpContext context)
  {
    context.Response.Cache.SetCacheablity(HttpCacheability.NoCache);
    context.Response.Cache.SetNoStore();
    context.Response.Cache.SetExpires(DateTime.MinValue);     ParseStatusCode(context, _returnStatus);
  }   /// <summary>
  /// Actually set up the status code at this point, and return.
  /// </summary>
  protected virtual void ParseStatusCode(HttpContext context, int statusCode)
  {
    context.Response.StatusCode = statusCode;
    context.Response.End();
  }   public bool IsReusable
  {
    get { return true; }
  }
} /// <summary>
/// This concrete implementation of the <see cref="StatusHandlerBase" /> class
/// sets up the http handler to return a status code of 500.
/// </summary>
public class Return500 : StatusHandlerBase
{
  public Return500() : base(500) {}
}

Now, one of the things I always like to do is to look for ways to abstract so even in a relatively trivial example like this, there’s abstraction. I’m sorry, but there you go - personality quirk and all of that. There you go though, an HttpHandler that returns a 500 status.