Returning empty arrays vs nulls

I could have said it better myself… thanks Wes.

Empty Arrays

Comments (11)

  1. Einar Hoest says:

    Well, why didn’t you? 😉

  2. Jerry Pisk says:

    I hope the CLR team won’t actually follow their own guidelines. Currently I can tell whether a web form didn’t include an input element (NameValueCollection.Get() will return null) from a request when the user didn’t fill it in (NameValueCollection.Get() will return will return an empty string). Now you may say I should use two different forms (which will differ by a single field) but why would I do that if I can reuse all the code except that single field (which is shown based on whather the user has enough rights to actually edit that particular field)? If I had no way to differentiate those two cases I wouldn’t know what error message to show the user (should I force somebody who doesn’t see the field to fill it out or should I allow people who have to fill it out to ignore the field?). Same applies to a lot of other cases, a Null XmlElement.GetAttribute() would mean the attribute is not there, empty string would show that the attribute is there but it’s an empty string. Nulls are valid values, no matter how difficult they may seem to few lazy developers. Btw if you so believe that no nulls should be returned, shouldn’t you apply the rule to anything that implements IEnumerable interface? Arrays are just one of many…

    As for Wes’ article:

    1. Reliability? Reliable code checks return values. If an object can be null (and CLR specs say any object reference can be null) then you need to check for nulls. Period. You could argue that 1/0 should evaluate to 0 so you wouldn’t throw an overflow exception and thus make your code more reliable.

    2. Simplicity? There are cases when a null object has a different meaning from an empty object.

    3. How about NameValueCollection.GetValues() or IDictionary.Item? Should they return an empty array even for names that don’t exist in the collection/dictionary? I think not but apparently everybody thinks it should.

  3. Jerry Pisk says:

    IDictionary.Item isn’t the best example, even though if your dictionary has arrays of values or strings it still applies.

  4. Paolo Molaro says:

    The same issue was discussed on the Mono mailing lists a few weeks ago, with the same suggestion to return arrays stored in static fields to avoid the memory allocation hit. What the blog entry overlooks, though, is that, while empty strings and arrays are immutable in their contents (there is none!) they cannot be freely shared. The reason is that they can be locked. Sure it’s a generally stupid thing to lock empty strings or arrays, but so is not checking for null:-)

    So, is the MS people willing to document that the methods in mscorlib/System/etc can return static references when the result is an empty array or string? Without at least that warning in the documentation, returning static references as an optimization is bound to break some code (there is already code out there that depends on some string methods returning the interned empty string, even if it’s not documented, it would not be surprising the same kind of broken assumptions were made about methods returning arrays). Documenting that returned empty arrays may come from a static reference would help to clear things up.

  5. Max says:

    >The reason is that they can be locked

    Shouldn’t this read: They can’t be locked?

  6. Panos Theofanopoulos says:

    Paolo : Not just lock, HashCodes are also different, but imho this optimization should be resolved by the runtime and not by FCL

    ie instead of static references, the Type class could have an instance property "Array EmptyArray {get;}" lazy constructed. Then every "new <T>[0]" or Arracy.Create for single *empty* dimensions is called, to return always the value of this property

    but i feel that is too late for it 🙁

  7. Brad,

    I applaud the effort of MS attempting to make a standard of this, but if it’s possible for either null or string.empty to be returned and because a chunk of all programming is related to validation/defensive programming, then why bother making a recommendation at all?

    Regardless of my own opinions, with all of the open source and multiple hands in the same pie making changes to a code base we should….we must attempt to catch all conditions. For example, let’s say I am developing a piece of code and you are one of my clients and I state I will never return null. Only String.Empty. Tomorrow I leave the company and bob next door takes over the code and forgets or doesn’t know about our agreement. Your code will break…..I know this is obvious to you. My point is that the recommendation only confuses the issue and therefore a bad recommendation.

    -Mathew Nolton

  8. Keith Hill says:

    I submitted an enhancement request a while back to add both an static object[] Array.Empty property and a static Array.IsEmptyOrNull method. There are enough places where you wind up pass an empty array of objects (MethodInfo.Invoke, delegate Invoke, etc) or you want to return an empty object array. The other nice thing about this property it that it can be a singleton so there are no extraneous heap allocs for emtpy object arrays.

    For arrays of types other than object, I wonder if you could do a static T[] Array.Empty<T> property? It might make code a bit more readable, maybe…

    public Foo[] GetFoos() {

    return Array.Empty<Foo>;


  9. Kit George says:

    It’s simply not seen as common as doing an IsNullOrEmpty on String. With an array, you want to check if the array you got back was null, but if not, the 99% case is to foreach (or for) over the array at that point. The loop of course, doesn’t care if its empty: if it is, it will simply loop zero times.

    Having said that, we can see situations where this is usefl: I’m writing a report, and I have a section which I want to write lines into (from an array). If I have no elements, I don’t want to even write the section. In this instance, IsNullOrEmpty is kind of useful. It’s simply not as common case as string.

    Having said that, I’ve entered a request for us to consider in the future Keith.

  10. Keith Hill says:

    Yeah, the string case is more much common. Thanks for the consideration though.

  11. Keith Hill says:

    Oops – that should have been "much more common". 🙂