blocks|key|1977590|text|那个代码示例很难读懂..。当变量可能为null时，必须检查null。但是，如果您想减少这一点，请确保返回对象的方法永远不会返回null，并且始终返回完全有效和构造的对象。让它在返回null的情况下抛出一个异常。返回null或-1或其他一些奇怪的约定不应替代错误处理。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1977591|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

That code example is hardly unreadable... You will have to check for nulls when there is a possibility of a variable being null. However, if you want to cut back on this, make sure that methods which return an object never return null and always return a fully valid and constructed object. Have it throw an exception in the case where you had it return null. Returning null or -1 or some other odd convention shouldn't be substituted for error handling.

blocks|key|443909|text|如果您只是要抛出一个异常，为什么不让语言运行时为您抛出它呢？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|443910|doc.Element.whatever("foo");|code-block|syntax|javascript|443911|您仍将得到一个NullPointerException+(或C#中的任何内容)，其中包含完整的跟踪信息。|443912|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|L|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|M|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

If you're just going to throw an exception anyway, why not let the language runtime throw it for you?

<pre><code>doc.Element.whatever("foo");
</code></pre>

You'll still get a NullPointerException (or whatever it is in C#) with full traceback information.

blocks|key|1977607|text|将它们向前推到函数的开头，并将它们排除在执行工作的代码中。如下所示：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1977608|if+(doc+==+null)
++++throw+new+ArgumentNullException("doc");
if+(doc.Element+==+null)
++++throw+new+ArgumentException("Element+cannot+be+null");
AndSoOn();+|code-block|syntax|javascript|1977609|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

Push them forward to the beginning of the function, and keep them out of the part of the code that does the work. Like this: 

<pre><code>if (doc == null)
 throw new ArgumentNullException("doc");
if (doc.Element == null)
 throw new ArgumentException("Element cannot be null");
AndSoOn(); 
</code></pre>

blocks|key|1977625|text|分离(静态？)函数调用：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1977626|public+static+void+CheckForNullObject(+object+Obj,+string+Message)+{
++++if(Obj+==+null){
++++++++throw+new+Exception(Message);
++++}
}|code-block|syntax|javascript|1977627|虽然这不是最好的选择，但它的可读性会更强一些。|1977628|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|L|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|M|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

Seperate (static?) function call:

<pre><code>public static void CheckForNullObject( object Obj, string Message) {
 if(Obj == null){
 throw new Exception(Message);
 }
}
</code></pre>

While this wouldn't be the best option, it would be a little more readable.

blocks|key|443954|text|如果属性初始化为适当的值，那么类的构造函数可能只应该创建对象吗？尽管如此，只有当实例在创建时具有最小数量的属性时才会创建实例，而不是您可以创建一个验证(+doc)方法，该方法本质上要做同样的事情，即检查对象的有效性。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|443955|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Perhaps the constructor of a class should only create the object if the properties are initialized to appropriate values? That being said an instance would only be created if it has the minimum number of properties upon creation other than that you could create a Validate(Doc doc) method that would essentially do the same thing, i.e. check the validity of the object.

blocks|key|755757|text|您可能对空对象模式感兴趣。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|755758|在很多情况下，它帮助我摆脱了空检查。|755759|示例(C%2B%2B)|755760|+++class+IThing
+++{+
++++++++public:
++++++++++virtual+void+DoThing()+=+0;
+++};+

+++class+NullThing+:+public+IThing
+++{+
++++++++public:
++++++++++virtual+void+DoThing()+{+/*no-op*/}
+++};+

+++class+RealThing+:+public+IThing
+++{+
++++++++public:
++++++++++virtual+void+DoThing()+{+/*does+something+real*/}
+++};+

+++int+main()
+++{
+++++++++NullThing+theNullInstance;+/*+often+a+singleton+or+static*/
+++++++++IThing*+thingy+=+&theNullInstance;+/*the+null+value*/

+++++++++//+Do+stuff+that+may+or+may+not+set++thingy+to+a+RealThing

+++++++++thingy->DoThing();+//+If+is+NullThing,+does+nothing,+otherwise+does+something

+++++++++//+Can+still+check+for+null+
+++++++++//+If+NullThing+is+a+singleton
+++++++++if+(thingy+==+&theNullInstance)
+++++++++{
++++++++++++++printf("Uhoh,+Null+thingy!\n");+
+++++++++}
+++}|code-block|syntax|javascript|755761|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Null_Object_pattern^0|4|5|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@$A|V|B|W|1|X]]|C|$]]|$1|D|3|E|5|6|7|Y|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|Z|8|@]|9|@]|C|$]]|$1|H|3|I|5|J|7|10|8|@]|9|@]|C|$K|L]]|$1|M|3|-4|5|6|7|11|8|@]|9|@]|C|$]]]|N|$O|$5|P|Q|R|C|$S|T]]]]

You may be interested in the <a href="http://en.wikipedia.org/wiki/Null_Object_pattern" rel="nofollow noreferrer">Null Object Pattern</a>. 

It has helped me in the past to get rid of null checks in a lot of instances.

Example (C++)

<pre><code> class IThing
 { 
 public:
 virtual void DoThing() = 0;
 }; 

 class NullThing : public IThing
 { 
 public:
 virtual void DoThing() { /*no-op*/}
 }; 

 class RealThing : public IThing
 { 
 public:
 virtual void DoThing() { /*does something real*/}
 }; 

 int main()
 {
 NullThing theNullInstance; /* often a singleton or static*/
 IThing* thingy = &amp;theNullInstance; /*the null value*/

 // Do stuff that may or may not set thingy to a RealThing

 thingy-&gt;DoThing(); // If is NullThing, does nothing, otherwise does something

 // Can still check for null 
 // If NullThing is a singleton
 if (thingy == &amp;theNullInstance)
 {
 printf("Uhoh, Null thingy!\n"); 
 }
 }
</code></pre>

blocks|key|1977694|text|不要捕捉异常，除非你能用它们做一些明智的事情。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1977695|在本例中，异常处理程序在默认情况下添加的值很少--也就是说，允许异常在调用链上传播。|1977696|在应用程序/线程的顶层，应该始终有异常处理程序来处理这些未处理的异常。|1977697|编辑:被投票否决，我觉得被误解了，也许我太敏感了;-)原始海报抛出的例外没有价值。它们不帮助最终用户，也不帮助开发人员。|1977698|应用程序中的顶级异常处理程序应该捕获这样的异常并将其记录下来。日志应该包括堆栈跟踪。这将告诉开发人员错误来自何处，并消除了许多真正没有用途的代码行。|1977699|如果异常增加了一些价值，那么我同意抛出它是合理的。但这里不是这样的。更糟糕的是，一旦您声明这是一个很好的原则，您将看到更多的代码行检查空引用，以至于代码中充斥着这些引用。|1977700|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|P|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|Q|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|R|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|S|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|M|$]]

Do NOT catch exceptions unless you are able to do something intelligent with them.

In this case, your exception handlers add little value over the default -- that is, letting the exceptions propagate back up the call chain.

At the top level(s) of your app/thread, there should always be exception handlers to deal with these uncaught exceptions.

EDIT: Being voted down, I feel misunderstood, maybe I'm too sensitive ;-). The exceptions that the original poster is throwing have no value. They don't help the end user and they don't help the developer.

The top level exception handlers in an application should catch an exception like this and log it. The log should include the stack trace. This tells the developer where the error came from and eliminates many lines of code that really serve no purpose.

IF the exception adds some value, then I'd agree that it is reasonable to throw it. But that isn't the case here. Even worse, once you state that this is a good principle, you'll see many more lines of code checking for null references, to the point that the code will be cluttered with them.

blocks|key|755786|text|如果一个典型的NullReferenceException会这样做，就不必费心检查，而只是让运行时抛出它。如果您需要添加上下文错误信息，为了日志记录或调试目的(或其他原因)，请继续，并将您的验证因素分解到不同的方法中。在这种情况下，我仍然鼓励您使用嵌套的原始异常抛出一个NullReferenceException。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|755787|当我被迫手动咀嚼深层XML文档时，我不得不做类似的事情。|755788|通常，我尝试在类中的接口边界上强制执行空正确性。然后，我可以在我的私有方法中忽略空检查。|755789|entityMap^0|7|M|3R|M|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@$9|M|A|N|B|C]|$9|O|A|P|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|Q|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|R|8|@]|D|@]|E|$]]|$1|J|3|-4|5|6|7|S|8|@]|D|@]|E|$]]]|K|$]]

If a typical <code>NullReferenceException</code> will do, don't bother checking and just let the runtime throw it. If you need at add contextual error information, for logging or debugging purposes (or whatever), go ahead and factor your validation out into a different method. I'd still encourage you to throw a <code>NullReferenceException</code> with the original exception nested, in that case.

I've had to do similar things when I've been forced to manually munge through deep XML documents.

In general, I try to enforce null-correctness at interface boundaries in my classes. I can then ignore null checks within my private methods.

blocks|key|755791|text|如果您觉得由于嵌套的ifs，它是不可读的，我的建议是这样重写：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|755792|if+(doc+==+null)
{
++throw+new+Exception("document+cannot+be+null");
}

if+(doc.Element+==+null)
{
++++throw+new+Exception("Element+cannot+be+null");
}

doc.Element.someMethod()|code-block|syntax|javascript|755793|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

If you feel it is unreadable because of the nested ifs, my suggestion would be to rewrite like this:

<pre><code>if (doc == null)
{
 throw new Exception("document cannot be null");
}

if (doc.Element == null)
{
 throw new Exception("Element cannot be null");
}

doc.Element.someMethod()
</code></pre>

blocks|key|1977781|text|你总是可以写：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1977782|if+(doc+==+null+&&+doc.Element+==+null
{

}|code-block|syntax|javascript|1977783|但是，您丢失了解决方案的粒度(例如，在例外情况下单独的消息)。|1977784|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|L|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|M|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

You could always write:

<pre><code>if (doc == null &amp;&amp; doc.Element == null
{

}
</code></pre>

But you lose the granularity with the solution one post above mine (e.g. separate messages in Exception).

blocks|key|444127|text|看一下"也许Monad“。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|444128|它满足了您对在C#中执行详细的空检查的可读方式的需求。|444129|还有也许codeplex项目|444130|entityMap|0|LINK|mutability|MUTABLE|url|http://incrediblejourneysintotheknown.blogspot.com/2008/12/maybe-monad-in-c.html|1|http://maybe.codeplex.com/^0|4|7|0|0|0|2|C|1|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@$A|S|B|T|1|U]]|C|$]]|$1|D|3|E|5|6|7|V|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|W|8|@]|9|@$A|X|B|Y|1|Z]]|C|$]]|$1|H|3|-4|5|6|7|10|8|@]|9|@]|C|$]]]|I|$J|$5|K|L|M|C|$N|O]]|P|$5|K|L|M|C|$N|Q]]]]

Have a look at the "<a href="http://incrediblejourneysintotheknown.blogspot.com/2008/12/maybe-monad-in-c.html" rel="nofollow noreferrer">Maybe Monad</a>".

It addresses your desire for a readable way to do verbose Null checks in C#.

There is also <a href="http://maybe.codeplex.com/" rel="nofollow noreferrer">Maybe codeplex project</a>

blocks|key|444181|text|要解决主张允许运行时抛出NullReferenceException的人，请执行以下操作：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|444182|我开始一个话题的主题是，主动抛出ArgumentNullException还是让运行时抛出NullReferenceException是个好主意。基本的共识是，采取积极主动的方法而不是NullReferenceException方法是个好主意。我并不是说他们是对的，主张反对的人是错的。我只是说，社会可能不同意你的观点。|offset|length|444183|我想指出的是，如果您正在执行这类检查的，则很有可能您做错了什么。要么您的方法做的太多了，要么您传递了太多的"tramp“参数(除了传递到另一个函数之外，没有其他用途的参数)。也许您应该考虑是否可以将代码更多地分解成单独的方法，还是将一些参数封装到对象中。|444184|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/368742/throwing-argumentnullexception^0|0|1|6|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@$D|R|E|S|1|T]]|A|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]]]

To address the people that advocate allowing the runtime to throw a NullReferenceException:

I <a href="https://stackoverflow.com/questions/368742/throwing-argumentnullexception">started a topic</a> on the subject of whether or not it is a good idea to proactively throw an ArgumentNullException or to let the runtime throw a NullReferenceException. The basic consensus was that it's a good idea to take the proactive approach rather than the NullReferenceException approach. I'm not necessarily saying that they're right and the people who advocate otherwise here are wrong. I'm just saying that the community may disagree with you.

What I would like to point out is that if you're doing a lot of these kinds of checks, chances are good that you're doing something wrong. Either your methods are doing too much or you're passing around too many "tramp" arguments (arguments that serve no purpose other than to be passed to another function). Perhaps you should consider whether you can break your code up more into separate methods or maybe encapsulate some of the arguments into an object.

blocks|key|444209|text|有几个选项(有些已经被其他人提到了)，所以我只是添加到列表中。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|444210|对于某些类型，使用空对象是有意义的。在这种情况下，您必须确保方法永远不会返回简单的null，而是始终返回实例(可能是null对象)。|ordered-list-item|444211|如果您想使用Paige建议的静态方法，甚至可以将其转换为扩展方法。您可以做类似的事情：
私有静态空ThrowIfNull(此对象o，字符串消息){+if+(o+=+null)返回；抛出新的ArgumentNullException(消息)；}|444212|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$]]|$1|E|3|F|5|D|7|K|8|@]|9|@]|A|$]]|$1|G|3|-4|5|6|7|L|8|@]|9|@]|A|$]]]|H|$]]

There are a couple of options (some have already been mentioned by others), so I'm just adding to the list.

<ol>
<li>For some types it makes sense to employ a null object. In that case, you have to make sure, that methods never return a simple null, but always return an instance (which may be the null object).</li>
<li>If you want to use the static method as suggested by Paige, you can even turn it into an extension method. You could do something similar to:

<pre><code> private static void ThrowIfNull(this object o, string message) {
 if (o != null) return;
 throw new ArgumentNullException(message);
 }
</code></pre></li>
</ol>

blocks|key|444239|text|你可能对Spec#感兴趣|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|444240|Spec#是API契约的一种正式语言，它使用非空类型()、先决条件、后置条件、对象不变量和模型程序(考虑了整个运行历史的行为契约)的构造来扩展。|blockquote|style|BOLD|444241|您可以让调用方负责确保参数不为空。Spec#使用感叹号表示：|444242|public+static+void+Clear(int[]!+xs)+//+xs+is+now+a+non-null+type
{
++++for+(int+i+=+0;+i+<+xs.Length;+i%2B%2B)
++++{
++++++++xs[i]+=+0;
++++}
}|code-block|syntax|javascript|444243|现在，Spec#编译器将检测到可能的空退出：|444244|int[]+xs+=+null;
Clear(xs);+++//+Error:+null+is+not+a+valid+argument|444245|作为附带说明，您还可能希望确保您没有破坏德米特定律。|444246|entityMap|0|LINK|mutability|MUTABLE|url|http://research.microsoft.com/en-us/projects/specsharp/|1|http://en.wikipedia.org/wiki/Law_of_Demeter^0|4|5|0|0|M|5|1Z|1|0|0|U|0|0|0|M|0|0|0|Q|K|5|1|0^^$0|@$1|2|3|4|5|6|7|15|8|@]|9|@$A|16|B|17|1|18]]|C|$]]|$1|D|3|E|5|F|7|19|8|@$A|1A|B|1B|G|H]|$A|1C|B|1D|G|H]]|9|@]|C|$]]|$1|I|3|J|5|6|7|1E|8|@$A|1F|B|1G|G|H]]|9|@]|C|$]]|$1|K|3|L|5|M|7|1H|8|@]|9|@]|C|$N|O]]|$1|P|3|Q|5|6|7|1I|8|@$A|1J|B|1K|G|H]]|9|@]|C|$]]|$1|R|3|S|5|M|7|1L|8|@]|9|@]|C|$N|O]]|$1|T|3|U|5|6|7|1M|8|@$A|1N|B|1O|G|H]]|9|@$A|1P|B|1Q|1|1R]]|C|$]]|$1|V|3|-4|5|6|7|1S|8|@]|9|@]|C|$]]]|W|$X|$5|Y|Z|10|C|$11|12]]|13|$5|Y|Z|10|C|$11|14]]]]

You might be interested in <a href="http://research.microsoft.com/en-us/projects/specsharp/" rel="noreferrer">Spec#</a>:

<blockquote>
 Spec# is a formal language for API contracts, which extends C# with constructs for
 non-null types, preconditions, postconditions, object invariants, 
 and model programs (behavioral contracts that take the history of the entire
 run into account).
</blockquote>

You can make it the caller's responsibility to make sure the argument is not null. Spec# uses the exclamation mark to denote this:

<pre><code>public static void Clear(int[]! xs) // xs is now a non-null type
{
 for (int i = 0; i &lt; xs.Length; i++)
 {
 xs[i] = 0;
 }
}
</code></pre>

Now the Spec# compiler, it will detect the possible null dereferences:

<pre><code>int[] xs = null;
Clear(xs); // Error: null is not a valid argument
</code></pre>

As a side note, you might also want to make sure you're not breaking the <a href="http://en.wikipedia.org/wiki/Law_of_Demeter" rel="noreferrer">Law of Demeter</a>.

blocks|key|755907|text|查看本文：一种流畅的C#参数验证方法|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|755908|它是由一个Paint.NET开发人员编写的。他使用扩展方法来简化和清理空检查代码。|755909|entityMap|0|LINK|mutability|MUTABLE|url|http://blog.getpaint.net/2008/12/06/a-fluent-approach-to-c-parameter-validation^0|5|D|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]]|C|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]]]

Check out this article: <a href="http://blog.getpaint.net/2008/12/06/a-fluent-approach-to-c-parameter-validation" rel="noreferrer">A fluent approach to C# parameter validation</a>

It's written by one of the Paint.NET Developers. He uses extension methods to simplify and clean up null checking code.

blocks|key|755928|text|合同是减少与空相关的问题和过度检查的关键因素。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|755929|在某些情况下，有些方法可能/应该返回null。如果您调用这样的方法，那么您只需检查。最好尽早检查一下。|755930|还有一些方法不允许返回null。不要检查它们的返回值。每个方法都有责任确保它履行自己的约定，因此作为该方法的调用者，您不必在意。|755931|有一些工具和语言特性可以帮助您记录和检查空检查和合同的正确性。对不起，我不能再解释了，因为我不是C#程序员。|755932|如果你想深入研究，我推荐这四个问题。它们大多以Java为中心，但是对于c#来说，几乎所有的东西都是正确的，有时答案甚至是为.net和C#定制的。|755933|如何避免java中的“！=null”语句？|unordered-list-item|offset|length|755934|如何在getter链中跟踪NullPointerException|755935|返回‘null’或抛出异常|755936|如何显示方法是否可能返回null|755937|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/271526/how-to-avoid-null-statements-in-java|1|https://stackoverflow.com/questions/410890/how-to-trace-a-nullpointerexception-in-a-chain-of-getters|2|https://stackoverflow.com/questions/175532/return-null-or-throw-exception|3|https://stackoverflow.com/questions/411447/how-to-show-if-a-method-may-return-null^0|0|0|0|0|0|0|L|0|0|0|X|1|0|0|D|2|0|0|G|3|0^^$0|@$1|2|3|4|5|6|7|18|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|19|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|1A|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|1B|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|1C|8|@]|9|@]|A|$]]|$1|J|3|K|5|L|7|1D|8|@]|9|@$M|1E|N|1F|1|1G]]|A|$]]|$1|O|3|P|5|L|7|1H|8|@]|9|@$M|1I|N|1J|1|1K]]|A|$]]|$1|Q|3|R|5|L|7|1L|8|@]|9|@$M|1M|N|1N|1|1O]]|A|$]]|$1|S|3|T|5|L|7|1P|8|@]|9|@$M|1Q|N|1R|1|1S]]|A|$]]|$1|U|3|-4|5|6|7|1T|8|@]|9|@]|A|$]]]|V|$W|$5|X|Y|Z|A|$10|11]]|12|$5|X|Y|Z|A|$10|13]]|14|$5|X|Y|Z|A|$10|15]]|16|$5|X|Y|Z|A|$10|17]]]]

Contracts are a key element in reducing null-related problems and superflous checks.

There are methods that may/should return null in some cases. If you call a method like this, then you simply have to check. It's best to check as early as possible.

And there are methods which are not allowed to return null. Don't check their return values. Each method is responsible to ensure it fulfils its own contract, so as a caller of that method you don't have to care. 

There are tools and language features to help you document and check the correctness of null-checking and contracts. Sorry I can't explain any more because I'm not a C# programmer.

If you want to dive in deeper, I recommend those four questions. They are mostly Java-centric, but almost everything is true for C# as well, and sometimes the answers are even customized to .net and c#.

<ul>
<li><a href="https://stackoverflow.com/questions/271526/how-to-avoid-null-statements-in-java">How to avoid “!= null” statements in java?</a></li>
<li><a href="https://stackoverflow.com/questions/410890/how-to-trace-a-nullpointerexception-in-a-chain-of-getters">How to trace a NullPointerException in a chain of getters</a></li>
<li><a href="https://stackoverflow.com/questions/175532/return-null-or-throw-exception">Return ‘null’ or throw exception</a></li>
<li><a href="https://stackoverflow.com/questions/411447/how-to-show-if-a-method-may-return-null">How to show if a method may return null</a></li>
</ul>

blocks|key|1978107|text|如果要检查传递给部分公共API的参数，那么就应该在方法的一开始使用“卫士子句”，就像丹·莫内戈所写的。如果您使用IsNotNull和其他方法创建或重用一些助手类，比如Assert，那么代码将很容易阅读(也许您确实只需要其中的一个)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1978108|您的代码如下所示：|1978109|Assert.IsNotNull(doc,+"document");
Assert.IsNotNull(doc.Element",+"Element");

//...+and+so+on|code-block|syntax|javascript|1978110|如果您要检查传递给您的一个私有方法的参数，那么您不应该有这样的检查，而应该添加一个契约(在方法文档中，或者如果您正在使用某些工具)，并且总是期望使用正确的参数来调用该方法。|1978111|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|N|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|O|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|P|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

If you are about to check parameter passed to part of your public API, then you should use "guard clauses" in the very beginning of your method like Dan Monego has wrote. The code will be easy reading if you create or reuse some helper class like Assert with methods like IsNotNull and others (maybe you really need only one of them).

Your code will look like:

<pre><code>Assert.IsNotNull(doc, "document");
Assert.IsNotNull(doc.Element", "Element");

//... and so on
</code></pre>

If you are about to check parameter passed to one of your private methods, then you shouldn't have such checks, instead of that you should add a contract (in method documentation or with some special declarations if you are using some tool for that) and always expect that this method will be called with correct parameters.

blocks|key|755414|text|下面是一个使用LINQ表达式的解决方案，检查链中的所有成员访问并返回实际值(如果所有内容都是有效的)：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|755415|public+static+T+CheckedGet<T>(Expression<Func<T>>+expr)+where+T+:+class
{
++++CheckAccess(expr);
++++return+expr.Compile().Invoke();
}

public+static+void+CheckAccess(Expression+expr)
{
++++switch+(expr.NodeType)
++++{
++++++++case+ExpressionType.Lambda:
++++++++++++CheckAccess((expr+as+LambdaExpression).Body);
++++++++++++break;
++++++++case+ExpressionType.MemberAccess:
++++++++++++{
++++++++++++++++CheckAccess((expr+as+MemberExpression).Expression);
++++++++++++++++var+value+=+Expression.Lambda(expr).Compile().DynamicInvoke();
++++++++++++++++if+(value+==+null)
++++++++++++++++{
++++++++++++++++++++throw+new+NullReferenceException(expr.ToString());
++++++++++++++++}
++++++++++++}
++++++++++++break;
++++++++case+ExpressionType.ArrayIndex:
++++++++++++{
++++++++++++++++var+binaryExpr+=+expr+as+BinaryExpression;
++++++++++++++++CheckAccess(binaryExpr.Left);
++++++++++++++++var+arrayLength+=+(int)Expression.Lambda(Expression.ArrayLength(binaryExpr.Left)).Compile().DynamicInvoke();
++++++++++++++++var+arrayIndex+=+(int)Expression.Lambda(binaryExpr.Right).Compile().DynamicInvoke();
++++++++++++++++if+(arrayIndex+>=+arrayLength)
++++++++++++++++{
++++++++++++++++++++throw+new+IndexOutOfRangeException(expr.ToString());
++++++++++++++++}
++++++++++++++++var+value+=+Expression.Lambda(expr).Compile().DynamicInvoke();
++++++++++++++++if+(value+==+null)
++++++++++++++++{
++++++++++++++++++++throw+new+NullReferenceException(expr.ToString());
++++++++++++++++}
++++++++++++}
++++++++++++break;
++++++++case+ExpressionType.Constant:
++++++++++++return;
++++}
}|code-block|syntax|javascript|755416|例如，在用法方面：|755417|var+val+=+CheckedGet(()+=>+classA.PropertyA.ArrayB[0].FieldC);|755418|它将通过适当的异常检查所有成员访问null和有效数组长度。|offset|length|style|CODE|755419|entityMap^0|0|0|0|0|H|4|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|T|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|U|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|V|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|W|8|@$M|X|N|Y|O|P]]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|R|$]]

Here is a solution using LINQ Expressions, checking all member access in chain and returning actual value if everything is valid:

<pre><code>public static T CheckedGet&lt;T&gt;(Expression&lt;Func&lt;T&gt;&gt; expr) where T : class
{
 CheckAccess(expr);
 return expr.Compile().Invoke();
}

public static void CheckAccess(Expression expr)
{
 switch (expr.NodeType)
 {
 case ExpressionType.Lambda:
 CheckAccess((expr as LambdaExpression).Body);
 break;
 case ExpressionType.MemberAccess:
 {
 CheckAccess((expr as MemberExpression).Expression);
 var value = Expression.Lambda(expr).Compile().DynamicInvoke();
 if (value == null)
 {
 throw new NullReferenceException(expr.ToString());
 }
 }
 break;
 case ExpressionType.ArrayIndex:
 {
 var binaryExpr = expr as BinaryExpression;
 CheckAccess(binaryExpr.Left);
 var arrayLength = (int)Expression.Lambda(Expression.ArrayLength(binaryExpr.Left)).Compile().DynamicInvoke();
 var arrayIndex = (int)Expression.Lambda(binaryExpr.Right).Compile().DynamicInvoke();
 if (arrayIndex &gt;= arrayLength)
 {
 throw new IndexOutOfRangeException(expr.ToString());
 }
 var value = Expression.Lambda(expr).Compile().DynamicInvoke();
 if (value == null)
 {
 throw new NullReferenceException(expr.ToString());
 }
 }
 break;
 case ExpressionType.Constant:
 return;
 }
}
</code></pre>

with usage, for example:

<pre><code>var val = CheckedGet(() =&gt; classA.PropertyA.ArrayB[0].FieldC);
</code></pre>

it will through proper exceptions checking all member access for <code>null</code> and valid array length.

Quite often, in programming we get situations where <code>null</code> checks show up in particularly large numbers. I'm talking about things like:

<pre><code>if (doc != null)
{
 if (doc.Element != null)
 {
 ... and so on
 }
 else
 throw new Exception("Element cannot be null");
} else {
 throw new Exception("document cannot be null");
}
</code></pre>

Basically, the whole thing turns into an unreadable nightmare, so I'm wondering: is there an easier way to describe what I'm trying to do above? (In addition to null checks, I get things like <code>string.IsNullOrEmpty</code> from time to time.)

Accepted answer: I accepted the answer that has <a href="http://blog.getpaint.net/2008/12/06/a-fluent-approach-to-c-parameter-validation/" rel="noreferrer">this link</a> because the approach described is innovative, and is precisely what I want. Thanks Shawn!

How can I manage the onslaught of null checks?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

在编程中，我们经常会遇到null检查的大量出现的情况。我说的是：if (doc != null){  if (doc.Element != null)  {    ... and so on  }  else    throw new Exception("Element cannot be null");} else...

问我如何处理空支票的冲击？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问我如何处理空支票的冲击？EN