what is the point of allowing invocation of extension methods on null objects? this is making me unnecessarily check for a null object in the extension method. AFAIK,i can't understand this? Please explain.
-
possible duplicate of [null target of extension method](http://stackoverflow.com/questions/3895032/null-target-of-extension-method) – BrokenGlass Mar 28 '11 at 13:11
-
Maybe a bad example, but I've seen: `Image img = ((Image)null).FromBytes(File.ReadAllBytes(file))` instead of a static helper class `ImageUtility`. – BrunoLM Mar 28 '11 at 13:13
-
6A distinct advantage is the ability to add nice extension methods that take nulls into account better than their instance method counterparts. A great example of this is SubString(). If you call this on a null reference, it will of course throw an exception. However, if you add a SubStringSafe() extension method that checks for null, you can eliminate a lot of duplicate code that checks for null. – RQDQ Mar 28 '11 at 13:13
-
5Adding to @RQDQ's example: I am using a simple IsNullOrEmpty extension method, whose usage feels more natural: `myStringVar.IsNullOrEmpty()`. – Daniel Hilgarth Mar 28 '11 at 13:24
-
@all i don't understand why people are voting to `close`? – Srinivas Reddy Thatiparthy Mar 28 '11 at 15:52
7 Answers
Extension methods are syntactic sugar of the C# language, they get compiled to normal static method calls in ILCode. A static method doesn't know anything about the parameters at compile time.

- 60,705
- 7
- 138
- 176
Simply put, why not?
You can sometimes skip the test if the first method you call within the extension would also throw the correct error.
You're essentially asking for the code to be different so that:
- Uses which are reasonable on a null object, become disallowed.
- Uses which don't need a null check (because it's implicit in something else) get the overhead of the needless check you want to happen automatically.
This seems a lot of an imposition on other uses just to save the one line of:
if(arg == null)throw new ArgumentNullException();

- 110,372
- 10
- 146
- 251
-
I use `ArgumentNullException`, as there is no such thing as an extension method in ILCode. Extension methods are just static methods, so `ArgumentNullException` is more appropiate. – Femaref Mar 28 '11 at 13:25
-
2@Femaref, I normally do too, but haven't seen anything clear on it. Of late I'm leaning to NullReference because when debugging a dev will more likely be looking at the C# with the method-style call than either IL or a static-style use of the method. Wonder if there's anything official in the MS coding guides. – Jon Hanna Mar 28 '11 at 13:27
-
1
-
@Femaref Think I'll stay as I am then, will edit answer accordingly. Also don't think I'll worry about letting a NullReferenceException bubble through though. – Jon Hanna Mar 28 '11 at 13:29
-
If it doesn't need a null check than don't implement it as an extension method. Follow the .NET Framework conventions and the principle of least astonishment. – Den Sep 26 '13 at 11:30
-
-
@Femaref since writing that, I've changed my mind. I'd now always throw `ArgumentNullException` on much the basis you and Den argued, (unless I could just do something meaningful with `null` of course). – Jon Hanna Jul 28 '15 at 15:51
Extension methods are just syntactic sugar. In reality they are static methods on another class, so since you can write
IEnumerable<int> foo = null;
Enumerable.Count(foo);
You can also write
IEnumerable<int> foo = null;
foo.Count();

- 428,835
- 81
- 738
- 806
-
You can write that :D But both code samples will throw an `ArgumentNullException`. `Count` extension method doesn't allow the **source** parameter to be null: http://msdn.microsoft.com/en-us/library/vstudio/bb338038.aspx – Yves M. Oct 02 '13 at 22:24
-
Then write your own that first checks for null and either throws up or returns Count()... – nurchi Sep 17 '14 at 01:51
Sometimes, allowing the extension method to be called on a null object simplifies your code by allowing you to move the null check into the method instead at the call site. For example, you may have an extension method that returns a List<T>
, but if called on a null object, returns an empty List<T>
.

- 51
- 2
Another beautiful example that wouldn't be possible otherwise:
public static bool IsNullOrEmpty(this string value)
{
return string.IsNullOrEmpty(value);
}
So you can use
string s = null;
if (s.IsNullOrEmpty()) // no null reference error!
...
Instead of
string s = null;
if (string.IsNullOrEmpty(s))
....

- 2,145
- 19
- 19
- Extension methods are transformed to static method invocations so the code will still need to check for null arguments as there is no way to avoid the static method to be called normally without the extension method syntactic sugar.
- Adding something like a check followed by a
NullArgumentException
could take execution time and the user may want to assert instead or use something else. - It would make the replacement more complex to explain or do automatically as the simple replacement of the extension method with the corresponding static method call will change the behavior of the code.
- There are legitimate case where you want to allow null arguments (for exemple conversions from an object model to another where a null object of one type is converted to a null object of the second type)

- 17,397
- 4
- 57
- 75
Extension methods are just static methods:
List<int> x = null;
x.Count()
Is equivalent to:
List<int> x = null;
System.Linq.EnumerableExtensions.Count(x);
//EnumerableExtensions may not be the class, but you get the idea

- 40,736
- 10
- 68
- 86