zalid / morelinq

Automatically exported from code.google.com/p/morelinq
Apache License 2.0
0 stars 0 forks source link

Change ArgumentNullException to early return. #95

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
Extension methods can operate on a null instances 
(http://stackoverflow.com/questions/847209/in-c-what-happens-when-you-call-an-ex
tension-method-on-a-null-object).

Rather than requiring the user always validate that they have a non-null 
enumerable before applying an operation, it is nice when the extension method 
supports null instances.

An example of where this is not the case in MoreLinq is ForEach:
https://code.google.com/p/morelinq/source/browse/MoreLinq/ForEach.cs

Notice that ForEach throws an ArgumentNullException if source is null.  
However, I believe that it would be entirely reasonable to simple return early 
instead.  This would allow the user to call ForEach on the enumerable without 
having to run it through something like (myEnumerable ?? 
Enumerable.Empty<MyType>()).

The ForEach is just an example, it would be nice if the entire MoreLinq library 
followed this pattern and treated null enumerations the same as empty 
enumerations.  e.g., Concat would just return an enumerable with one item if 
the source was null, the same as you would get if the source was empty.

Original issue reported on code.google.com by mi...@zoltu.net on 17 Oct 2014 at 12:29

GoogleCodeExporter commented 8 years ago
MoreLINQ is just extensions to LINQ to Objects and in that spirit, it does null 
argument checking on the source(s) just like all standard LINQ operators. It 
would be odd and confusing to have code that using MoreLINQ and LINQ in the 
same query to have a mix of two policies and the reader having to remember when 
it's okay to send null and when not. Even if you can afford to send null 
sources to MoreLINQ methods, you would to mask null with an empty sequence 
before calling the LINQ methods. The best policy is to write functions that 
don't return null sequences. If you have no control over the source of such 
functions then the next best course of action is to mask null with an empty 
sequence early on (when function returns the result) so that each call site is 
not polluted with null-masking. If `source ?? Enumerable.Empty<T>()` looks 
wordy, you can have a single extension method, called MaskNull for example, 
that hides that and type inference wouldn't even require you to specify the 
type for T (which is even better than Enumerable.Empty<T> because you can even 
use it for anonymously projected types).

Original comment by azizatif on 17 Oct 2014 at 6:19