C# Event handlers: a good idea immediately superseded by a BETTER one

When you have events in C#, you need to check to make sure they’re not null before firing them. They will be null if no one has ever registered for the event before. So you gotta do this:

namespace ConsoleApplication1
{
  class Program
  {
    public event EventHandler<EventArgs> someEvent;
    
    static void Main(string[] args)
    {
      // Imagine something happened, need to fire event
      if(someEvent != null) // Don't forget this vital null check!
         someEvent(this, EventArgs.Empty);
    } 

If you forget the null check, you will get a null reference exception if no one has registered for your event.

So here’s the “only good idea” (to be superseded below with the “great idea”)

The “only good idea” is to add an empty delegate to the event immediately when you declare it. Like this:

public event EventHandler<EventArgs> someEvent = delegate {};

I used to think that was a fabulous idea. After all, it has a lot of benefits. Now, you can freely just fire the event. The only overhead is that it will always call your empty delegate, which is the overhead of one unnecessary method call (not usually a big deal).

But here’s the better idea: Define an Extension Method on EventHandler that does the null check for you!

This is better because it is more readable and because it gets rid of that slight performance overhead of the empty delegate.

Here’s how:

public static void Fire<T>(this EventHandler<T> self, object sender, T args) where T : EventArgs
{
   if(self != null) self(sender, args);
}

Then, when it is time to fire an event, you do this:

someEvent.Fire(this, EventArgs.Empty);

I love it. You see, what is happening here is that, even though much of the community knows the new C# 3.0 language features pretty well, we continue to find new, powerful, delightful ways to use them.

By the way, the first place I learned this technique was from this question on StackOverflow.

Nice C# idiom for parameterless lambdas

The C# syntax for a lambda with no parameters is kind of ugly:

public static void SomeMethod(Person person)
{
   Console.WriteLine( ()=> person.FirstName );
   // The ugly syntax is: ()=> person.FirstName
}

However, there is a nice, relatively new idiom springing up that makes it a little better. The idiom is to use underscore (“_”) as the parameter. Underscore is a valid name for an identifier in C#.

The convention is that, as the idiom becomes more widespread, people reading your code will know that you would never name a meaningful parameter with underscore, so therefore they know you’re going to ignore the parameter. So in effect, they understand that the intent is a parameterless lambda.

As a result, you wind up with this:

public static void SomeMethod(Person person)
{
   Console.WriteLine( _=> person.FirstName );
}

There’s another reason this idiom is appealing: its harmony with F#. F# is a language on the rise, and we’re likely to see more and more projects which have a mix of F# and C#. In F# (and many other functional languages as well), there is a key language feature called pattern matching. At an over-simplified level, it is like a case statement. And there is syntax for a “wild card” pattern that matches everything. That syntax happens to be underscore! More specifically, when used in an F# pattern match, the underscore means, “Match whatever input I’m being compared to, and I don’t plan to use the value of that input in the expression I’m about to execute.” Which is almost exactly the same meaning we’re trying to express here.

Of course, you’ll have to decide for yourself whether you like the underscore or the original ()=> syntax better. Clearly that’s a subjective matter.

Also, beware that sometimes the two aren’t interchangeable, depending on what you’re doing with the lambda. If you use the underscore idiom, then of course you really do have a single-parameter lambda. If you’re passing the lambda to a method that is going to require a zero-parameter lambda (because it takes an expression tree from the lambda or something like that), then the underscore idiom is not going to work.

You can find more info here.

Some more good ideas about parameter validation in C#

As you can tell from several recent posts, I’m very interested in good syntax for parameter validation. The new features in C# 3.0 make so many things possible. I found another excellent post, from John Gilliland. He “amplifies” each plain old argument value into an ArgumentEx<T> instance, and then hangs extension methods such as “NotNull” and “InRange” off of ArgumentEx<T>. He uses an implicit conversion operator to make it easy to treat an ArgumentEx<T> as the plain old argument value.

Very nice, very thorough. Check it out. I’d like to combine elements of his approach with the lambda expression idea that allows you to avoid specifying both the parameter and the parameter name as a string.

Example where calling Extension Methods on null references is useful: Parameter Validation

In a recent post, I pointed out that extension methods can be called on null references. For example, this works perfectly fine:

public static void PrintToConsole(this string self)
{
   if(self != null)
      Console.WriteLine("The string is: " + self);
   else
      Console.WriteLine("The string is NULL.");
}

// Elsewhere in the code
string myString = null;
myString.PrintToConsole();

I said I’d give some examples of where this would actually be useful (not just a gimmick as it might appear on first blush).

One such case is parameter validation. Rick Brewster has come up with a fantastic approach for parameter validation, which lets your code look something like this:

public static void Copy(T[] dst, long dstOffset, T[] src, long srcOffset, long length)
{
    Validate.Begin()
     .IsNotNull(dst, “dst”)
     .IsNotNull(src, “src”)
     .Check()
     .IsPositive(length)
     .IsIndexInRange(dst, dstOffset, “dstOffset”)
     .IsIndexInRange(dst, dstOffset + length, “dstOffset + length”)
     .IsIndexInRange(src, srcOffset, “srcOffset”)
     .IsIndexInRange(src, srcOffset + length, “srcOffset + length”)
     .Check();
  
     // Further code snipped.
}

No doubt that’s beautiful syntax. But one of Rick’s main goals was this: Incur the least possible overhead if the parameters are all correct. In particular, don’t instantiate any additional objects if the parameters are correct.

And the way this is achieved depends on the fact that extension methods can be called on null references. If all the parameters are OK, the Begin() method, the IsNotNull() method, and so on, all return null. However, they still have a return type, and that return type has extension methods on it called “Begin”, “IsNotNull”, “IsPositive” and so forth.

You can learn more about Rick’s approach here and here.

C# Delights: Extension methods can be called on null references (and that’s extremely useful)

Did you know that C# extension methods can be called on null references?? Yes, they can. For example, the following method …

public static void PrintToConsole(this string self)
{
   if(self != null)
      Console.WriteLine("The string is: " + self);
   else
      Console.WriteLine("The string is NULL.");
}

… can be called as follows:

string someString = null;

someString.PrintToConsole();

The output would be:
The string is NULL.

Is this just a gimmick? You might think so at first blush, but it is actually remarkably useful. I’ll write another post soon giving some examples of when it is useful. Here’s one hint: imagine a case where you don’t want the overhead of instantiating objects unless you’re in an unusual situation. (OK, here’s another hint … what if you want to write code that applies business logic to non-null values, but seamlessly ignores nulls, so that the code doesn’t have to be all cluttered up with null checks).

NHibernate and FluentNHibernate Rock!

Saw a very interesting presentation last night by Brendan Erwin, on how he uses NHibernate and FluentNHibernate. FluentNHibernate is a tool that lets you specify your mappings between the database and your domain objects in C# code, instead of in XML. This is awesome for several reasons:

1. You can refactor common bits of mappings into helper methods, thus keeping your mappings more DRY.
2. It is much more refactoring friendly. It uses lambda expressions and is able to avoid strings for property names. Thus if you rename a property using .NET refactoring or Resharper, the update applies everywhere.
3. You get intellisense as you create and edit mappings. You’d be surprised how greatly this improves the process.

Git on Windows and behind Firewalls

I do .NET development on my Mac, and for source code management I use Git from the Mac Terminal window. But once I’ve developed the code, I have to get it onto the company’s development server, which is a Windows machine behind a firewall. I do this using git on Windows.

There are multiple choices for Git on Windows, but I chose the MSysGit route. I used putty to get around the firewall issues. I also had to set the whitespace setting in the MSysGit repo to match what it is by default on Unix — without that, things still worked but Git would change Windows-typical line endings to Unix line endings, causing a diff to think every single line had changed.

Once I worked through all that, everything worked beautifully (and it has for months now). I code on my machine, push to a GitHub repo, and the pull from GitHub to the Development Server (using MSysGit / Putty).

I culled through 100’s of articles while getting this set up. Here are the hand-picked articles that were the most helpful for me.

• http://kylecordes.com/2008/04/30/git-windows-go/
• http://blog.codeslower.com/2008/8/Using-PuTTY-and-SSL-to-securely-access-GitHub-repositories-via-SSH
• http://souptonuts.sourceforge.net/sshtips.htm
• http://www.andrewtrommer.com/2008/10/27/git-and-corporate-proxies/
• http://richfrog.curzons.net/2008/05/git-with-putty-on-windows.html

C# Delights: You can put Extension Methods onto Enums!

Often, you need to associate other information with the members of an Enum. For example, say you have the following enum:

public enum DaysOfWeek : int
{
   Sunday = 1,
   Monday = 2,
   Tuesday = 3,
   Wednesday = 4,
   Thursday = 5,
   Friday = 6,
   Saturday = 7
}

That’s all well and good. But say you need to associate additional information with each enum member. For example, say your legacy database represents the days of the week with the following 2 letter codes: “Sn”, “Mo”, “Te”, “Wn”, “Tr”, “Fi”, “St”. Notice I picked codes that are not intuitive and are not always the first 2 characters. Crazy, but we all know legacy databases can be crazy.

Also, let’s imagine that your company needs to associate a decimal hourly rate with each day, representing the fact that you charge different rates for different days.

C# has a very nice, new way you can do this. Before C# 3.0, the best way I knew of to handle this was to not use an Enum at all. Rather, I would make a class that was much like a singleton, but with more than one instance. It would have a private constructor, so that no other classes outside of it could make instances of it. However, it would expose static properties with the exact set of instances that were allowed (7 in our case, and the properties would be named “Sunday”, “Monday”, etc.). Each instance would have properties for “DatabaseCode”, “Name” and “HourlyRate”. That’s not bad, but the new way is better in many cases.

The new way is this: You can place extension methods onto Enums! So, in our case, we would do the following:

public static class DaysOfWeekExtensions
{
   private static string[] databaseCodes = new string[] { "Sn", "Mo", "Te",
      "Wn", "Tr", "Fi", "St" };

   private static decimal[] rates = new decimal[] { 2.5m, 3.6m, 0m, 1.2m,
      8.8m, 42m, 3.6m };

   public static string DatabaseCode(this DaysOfWeek self)
   {
      int index = (int)self - 1;
      return databaseCodes[index];
   }

   public static decimal HourlyRate(this DaysOfWeek self)
   {
       int index = (int)self - 1;
       return rates[index];
   }
}

And then you’d use it like this:

Console.WriteLine("For Tuesday, the database code is " + 
   DaysOfWeek.Tuesday.DatabaseCode() + " and we charge " +
   DaysOfWeek.Tuesday.HourlyRate() + ".");

Click here for another example.

Elegant, appealing parameter validation syntax in C# 3.0

This is a VERY cool trick that leads to much improved syntax for parameter validation in C# 3.0. (Kudos to Jon Fuller).

Often when writing methods, you need to validate that the parameters you’ve received are valid. So you might write some code like this:

public void SomeMethod(string firstName, decimal salary, int ageInYears)
{
   if(firstName == null)
      throw new WhateverException("The 'firstName' parameter cannot be null.");

   if(salary < 0)
      throw new WhateverException("The salary must not be negative.");

   // And so on ... you get the idea.
}
&#91;/sourcecode&#93;

When you write that in several places, it is only natural to start thinking about a <em>helper</em> to get rid of some of the duplication. Millions of ways to go about it, and it might look something like this:


public void SomeMethod(string firstName, decimal salary, int ageInYears)
{
   ValidationHelper.NotNull("firstName", firstName);
   ValidationHelper.NotNegative("salary", salary);
   // And so on ... you get the idea
}

The thing that sucks about this is that you have to provide the parameter name as a string. You want the error message to say, “The ‘salary’ parameter was severely messed up.” Therefore, it needs “salary” as a string. This is not DRY, because you’ve already designated which parameter you mean. Also, it is not friendly for refactoring.

And C# 3.0 lets you get rid of it!!!! Here’s how:

public void SomeMethod(string firstName, decimal salary, int ageInYears)
{
   ValidationHelper.NotNull( ()=> firstName );
}

The NotNull method is defined as follows:

public static void NotNull(Expression<Func> expr)
{
  if ( ! expr.Compile()().Equals(default(T)))
    return;

  var param = (MemberExpression)expr.Body;
  throw new WhateverException("The parameter '" + param.Member.Name + "' cannot be null.");
}

Notice that the exception message does contain the string “firstName”, but that there IS NO SUCH STRING anywhere in the code! How does this work?

The NotNull method takes an Expression. Because of that, our lambda expression will be turned into an expression tree. That expression tree has one node in it, which is a member expression asking for the value of the “firstName” member. (Why is it a member instead of a parameter? Because C# is generating a closure here and capturing the local variable named “firstName” into the closure. Under the hood, this becomes a class with a member named “firstName”. Our lambda expression is then an expression which asks for the value of that field, which means it is a member expression. And then that expression is turned into an expression tree).

The upshot is that we have no strings, but the helper code can obtain and use the string. Very nice!

You can find more about this here.