C# Extension Methods and Null References

With extension methods in C# 3.0, you can create methods that operate as if they were instance methods of other classes. You can "add" methods to any class, even to core classes like System.String and System.Object.

This example creates two string extensions: 

public static class StringExtensions {
  public static string HtmlEncode(this string input) {
    return AntiXss.HtmlEncode(input);
  }
  public static int ToInt32(this string s) {
    return Int32.Parse(s);
  }
}

(I used the HtmlEncode method implemented in the Anti-Cross Site Scripting Library.)

The way to use extension methods is to call them as if they were instances of the extended class itself (given as the first parameter to the extension methods): 

int input = "123".ToInt32();
...
string safeString = unsafeString.HtmlEncode();

Or you can use them as normal static methods (it has the same effect as above): 

int input = StringExtensions.ToInt32("123");
...
string safeString = StringExtensions.HtmlEncode(unsafeString);

Extension methods are pure syntactic sugar. The compiler translates all extension method calls to calls to the corresponding static methods. I don't think it even qualifies as monkey patching. The syntax is convenient for the caller because he can pretend (or even believe) that the class has always had that method.

Now stop and think about null references. Normal instance methods can't be called with null references, they'll immediately throw a NullReferenceException. Extension methods can be called with null references (remember, they're just glorified static methods), and it's up to the developer to deal with them.

In short, the new syntax of extension methods can hide unintended semantic problems. The ToInt32 method will work as expected, because int.Parse will throw an ArgumentNullException (not a NullReferenceException, but still...) on null references. But the HtmlEncode method will actually return null, which might not be what's expected of it.

The developer that calls the extension method might not be the same that wrote it, so it's important for extension methods not only to look like instance methods, but to behave like them too. But, don't throw a NullReferenceException because it should be reserved for the runtime (it could add extra semantics to it). Instead, throw an ArgumentNullException when the instance parameter is null. Even in the ToInt32 method it should be done. It shows clear intentions and it's safer should the implementation change: 

public static class StringExtensions {
  public static string HtmlEncode(this string input) {
    if (input == null) throw new ArgumentNullException();
    return AntiXss.HtmlEncode(input);
  }
  public static int ToInt32(this string s) {
    if (s == null) throw new ArgumentNullException();
    return Int32.Parse(s);
  }
}

It might make sense to break this rule if the extension method explicitly tests for null, and its name indicates it duly: 

public static class StringNullExtensions {
  public static bool IsNullOrEmpty(this string s) {
    return string.IsNullOrEmpty(s);
  }
  public static bool IsNullOrBlank(this string s) {
    return s == null || s.Trim().Length == 0;
  }
}

Update: the ArgumentNullException is not ideal, so it would be interesting if C# (or the CLI) brought extensions methods even closer to instance methods, by automatically checking the instance parameter and throwing a NullReferenceException appropriately. A simple annotation would suffice. For example, we could use this! instead of this on methods that can't operate on null references: 

  // NOTE: not valid C#

  public static string HtmlEncode(this! string input) ...

  public static bool IsNullOrBlank(this string s) ...

Comments

Post a Comment

Popular posts from this blog

The Acyclic Visitor Pattern

Knock knock The visitor design pattern is a way to add new operations to a hierarchy of classes without having to change the hierarchy itself. For example, with a simple hierarchy of fruits, you can have an IFruitVisitor interface that operates on the different classes in the hierarchy (in C#): interface IFruitVisitor { void Visit(Apple apple); void Visit(Grape grape); } The hierarchy classes then accept the visitor and fulfil the double-dispatching necessary to call the right Visit method: abstract class Fruit { public abstract void Accept(IFruitVisitor visitor); } class Apple : Fruit { public override void Accept(IFruitVisitor visitor) { visitor.Visit(this); } } class Grape : Fruit { public int NumberOfGrapes { get; set; } public override void Accept(IFruitVisitor visitor) { visitor.Visit(this); } } Note how each Accept method looks the same but is actually dispatching to a different method in the visitor ( Visit(Apple) and Visit(Grape) ).
Read more

Some OO Design

"The critical design tool for software development is a mind well educated in design principles. It is not the UML or any other technology." - Craig Larman I've recently found the following interview question on stackoverflow : Basic sales tax is applicable at a rate of 10% on all goods, except books, food, and medical products that are exempt. Import duty is an additional sales tax applicable on all imported goods at a rate of 5%, with no exemptions. When I purchase items I receive a receipt which lists the name of all the items and their price (including tax), finishing with the total cost of the items, and the total amounts of sales taxes paid. The rounding rules for sales tax are that for a tax rate of n%, a shelf price of p contains (np/100 rounded up to the nearest 0.05) amount of sales tax. This is a very familiar example that can be used as a really good gauge of various software development skills. There are many different ways to solve this problem.
Read more

C# Mixins With State

With the C# quasi-mixin pattern , one of the biggest limitations is that the mixins can't introduce state to a class. An alternative was for the mixin interface to require the composing classes to implement a property that the mixin would use as its own, as demonstrated in this example . In the .NET Framework 4.0, the ConditionalWeakTable<TKey, TValue> class can be used to associate arbitrary state to any instance. It's thread safe and it keeps a dictionary of weak references from the target instance to its associated state. If a target instance has no references outside the conditional weak table, then it can be reclaimed by the garbage collector. When that happens, its entry in the table is removed. This makes it possible for a mixin-like class to maintain state for the instances it extends. Let's look at a mixin for a message container: public enum MessageType { Error, Warning, Info } public class Message { public readonly MessageType Type;
Read more