Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
I could have said it better myself… thanks Wes.
Comments
- Anonymous
February 23, 2004
Well, why didn't you? ;-) - Anonymous
February 23, 2004
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. - Anonymous
February 23, 2004
IDictionary.Item isn't the best example, even though if your dictionary has arrays of values or strings it still applies. - Anonymous
February 23, 2004
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. - Anonymous
February 24, 2004
>The reason is that they can be locked
Shouldn't this read: They can't be locked? - Anonymous
February 24, 2004
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 :-( - Anonymous
February 26, 2004
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 - Anonymous
February 27, 2004
The comment has been removed - Anonymous
March 03, 2004
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. - Anonymous
March 03, 2004
Yeah, the string case is more much common. Thanks for the consideration though. - Anonymous
March 03, 2004
Oops - that should have been "much more common". :-)