这段程序运行没问题，意外的是在第一个period节点上，它的Name属性是什么呢，一直以来我都弄错了，可能还有许多人也弄错了。正确答案是String.Empty，而不是null。而且即使我在ConfigurationProperty加上DefaultValue=null，Name返回的依然是String.Empty。

　　在我看来，null应该用于表示一种在我们预料之外的状态，包括传入的参数和返回的结果。比如一段从数据库读取记录的代码，如果执行中出现异常，则返回null，和正常执行后未找到任何匹配记录的情况截然不同。同理，对于节点的name属性未定义的情况，显然也不同于定义了name=”"的情况，返回null是合理的。而ConfigurationElement不允许string属性为null，可能有某方面的考虑，但这应该是个Bug，因为它返回值含混不清，是对string空值的误解。

　　请再来看另一个例子：如果这个返回值变成了参数的情况。在实际软件中，读取XML数据源时，通常要进行架构验证，比如像下面这样：

　　这段代码有一个问题，它未判断targetNamespace的是Null还是String.Empty。对于XmlSchemaSet的Add方法，targetNamespace参数如果为null，则表示使用xsd文件中定义的命名空间，而如果传入String.Empty，XmlSchemaSet依然认为，是我们手动指定了一个空的命名空间，而这完全不是我们想要的。

　　如果在xsd文件中定义了targetNamespace，我们手动指定的namespace必须与之一致，否则将抛出异常。而xsd文件中的targetNameSpace属性，你可以不加它，但加了就不允许空值。换句话说，我们传入的为String.Empty时targetNameSpace参数时，xsd中只要有targetNamespace的定义，程序必然出错。下图也是上面代码执行的结果，和传null值的情况有天壤之别。

　　我们不能怪罪写Xml验证的人太马虎，微软一个内部框架中就有这个问题。归根究底，是.Net Framework对null的误用，导致了我们的误解。

　　首先，ConfigurationElement类对返回值的误用，属性值该是null却返回String.Empty。

　　其次，XmlSchemaSet类的Add方法有一定问题，应该提供一个重载函数，不需要传入为null的targetNamespace参数，直接用xsd文件中的对应属性。 不但方便，也减少出错的机会。当然，它正确的区分了null和empty的含义，这点还是值得称赞的。

　　连.Net Framework对null使用上都有如此的问题，我们写程序时，应该更小心翼翼，对付这个难以捉摸、令人纠结的null。