避免引用异常引用 [英] avoiding null reference exceptions

问题描述

显然，代码中绝大多数错误都是空引用异常。有没有一般技术来避免遇到空引用错误？

除非我错了，我知道在F＃语言中不可能有空值。但是这不是问题，我在问如何避免C＃语言中的空引用错误。

解决方案

引用异常显示给用户，这表示由于开发人员错误导致的代码缺陷。以下是有关如何防止这些错误的一些想法。

对于关心软件质量，并且也使用the.net编程平台的人来说，我的最佳建议是安装和使用Microsoft代码合同（ http://msdn.microsoft.com/en-us/devlabs/dd491992.aspx ） 。它包括进行运行时检查和静态验证的功能。将这些合同构建到您的代码中的基本功能是包含在4.0版本的.NET框架中。如果您对代码质量感兴趣，这听起来像是您，您可能会喜欢使用Microsoft代码合同。

使用Microsoft代码合约，您可以保护您的方法通过添加像Contract.Requires（customer！= null）;这样的前提条件的空值。添加这样的先决条件等同于许多其他人在上述评论中推荐的做法。在代码合同之前，我建议你做这样的事情

  if（customer == null）{throw new ArgumentNullException 客户）;} 
  

现在我推荐

  Contract.Requires（customer！= null）; 
  

然后，您可以启用运行时检查系统，尽早捕获这些缺陷，领先您可以诊断和纠正有缺陷的代码。但不要让我给你的印象是，代码合同只是一种花哨的方法来替换参数null异常。他们比这更强大。
通过Microsoft代码合同，您还可以运行静态检查器，并要求它调查代码中可能发生空引用异常的可能站点。静态检查器需要更多的经验才能轻松使用。我不会推荐给初学者。但是请随便试试看看。

研究NULL参考错误的前提

在这个线索中有一些争论是空参考错误是否是一个重大问题。一个长期的答案在下面。对于不希望通过的人来说，我将总结一下。

• 微软领先的研究人员在
  程序中正确性规范＃和
  代码合同项目认为它是
  a问题值得寻址。


• Dr。 Bertrand Meyer和ISE的
  软件工程师团队，
  开发并支持Eiffel
  编程语言，也认为
  是值得寻求的问题。


• 在我自己开发普通软件的商业经验中，我经常看到空引用错误，我想解决我自己的产品和做法中的问题。

多年来，微软投资了旨在提高软件质量的研究。他们的努力之一是Spec＃项目。引用Microsoft代码合同，这是我对于.net 4.0框架的看法中最激动人心的事情之一，它是Spec＃研究团队早期工作的一个成果。

关于您的评论代码中绝大多数错误都是空引用异常，我相信这是限制词绝大多数会引起一些分歧。短语大多数表明，大概70-90％的故障都有一个空引用异常作为根本原因。这对我来说似乎太高了。我更喜欢引用Microsoft Spec＃的研究。在他们的文章规范＃编程系统：概述中，Mike Barnett，K. Rustan M. Leino和Wolfram Schulte。在CASSIS 2004年，LNCS vol。 3362，Springer，2004，他们写了

1.0非空类型现代程序中的许多错误表现为
null-dereference错误，建议
一个编程
语言的重要性，提供
的能力，以区分
可能评估为null的表达式，那些
肯定不会一些实验性的
证据，参见[24,22]）。实际上，我们
想根除所有null
解除引用错误。

这是一个可能的来源微软熟悉这项研究的人。本文可在Spec＃网站上找到。

我已经复制了下面的引用文件22和24，并为了方便起见，包含了ISBN。

• Manuel Fahndrich和K. Rustan M. Leino。在
  面向对象语言中声明和检查非空类型。在2003年ACM会议论文集面向对象的
  编程，系统，语言和应用程序，OOPSLA 2003，第38卷，数字
  11在SIGPLAN通知，第302-312页。 ACM，2003年11月。isbn = {1-58113-712-5}，




• Cormac Flanagan，K. Rustan M. Leino，Mark Lillibridge，Greg Nelson ，James B. Saxe，
  和Raymie Stata。 Java的扩展静态检查。在2002年ACM
  SIGPLAN语言设计和实现编程会议（PLDI）的会议记录中，卷
  37，SIGPLAN通知中的第5页，第234-245页。 ACM，2002年5月。

我查看了这些参考。第一个参考文献指出了一些实验，他们检查了自己的代码可能的空参考缺陷。他们不仅找到了几个，而且在许多情况下，潜在的无效参考的识别表明了设计的更广泛的问题。

第二个引用没有提供有关空引用错误是有问题的断言的任何具体证据。但作者确实表示，在他们的经验中，这些空参考错误是软件缺陷的重要来源。然后，本文将介绍如何尝试消除这些缺陷。

我还记得在最近发布的埃菲尔的ISE公告中看到有关这方面的内容。他们将这个问题称为无效安全，并且像Bertrand Meyer博士所启发或开发的许多事情一样，他们对这个问题进行了雄辩的教育描述，以及他们在语言和工具中如何防止这种情况。我建议您阅读他们的文章 http：//doc.eiffel .com / book / method / void-safety-background-definition-and-tools 了解更多信息。

如果您想了解有关Microsoft代码的更多信息合同，最近出现了大量的文章。您还可以通过使用编程与合同来查看我的博客http：SLASH SLASH codecontracts.info，主要致力于关于软件质量的对话。

Apparently the vast majority of errors in code are null reference exceptions. Are there any general techniques to avoid encountering null reference errors?

Unless I am mistaken, I am aware that in languages such as F# is it not possible to have a null value. But thats not the question, I'm asking how to avoid null reference errors in languages such as C#.

解决方案

When a null reference exception is displayed to the user, this indicates a defect in the code resulting from an error on the part of the developer. Here are some ideas on how to prevent these errors.

My top recommendation for people who care about software quality, and are also using the.net programming platform, is to install and use Microsoft code contracts ( http://msdn.microsoft.com/en-us/devlabs/dd491992.aspx ). It includes capabilities to do run-time checking and static verification. The essential capability to build these contracts into your code is being included in the 4.0 version of the.net framework. If you are interested in code quality, and it sounds like you are, you may really enjoy using Microsoft code contracts.

With Microsoft code contracts, you can guard your method from null values by adding preconditions like this "Contract.Requires(customer != null);". Adding a precondition like this is equivalent to the practice recommended by many others in their comments above. Prior to code contracts, I would have recommended you do something like this

if (customer == null) {throw new ArgumentNullException("customer");}

Now I recommend

Contract.Requires(customer != null);

You can then enable the run-time checking system which will catch these defects as early as possible, leading you towards diagnosis and correction of the defective code. But don't let me give you the impression that code contracts are simply a fancy way to replace argument null exceptions. They are much more powerful than that. With Microsoft code contracts, you can also run the static checker, and ask it to investigate possible sites in your code where null reference exceptions might occur. The static checker requires a bit more experience to use easily. I would not recommend it first for beginners. But feel free to try it out and see for yourself.

RESEARCH ON THE PREVALENCE OF NULL REFERENCE ERRORS

There has been some debate in this thread on whether null reference errors are a significant problem. A long-winded answer is below. For people who don't want to wade through that, I will summarize.

• Microsoft's leading researchers in program correctness on the Spec# and code contracts projects believe it is a problem worth addressing.
• Dr. Bertrand Meyer and the team of software engineers at ISE, who developed and support the Eiffel programming language, also believe it is a problem worth addressing.
• In my own commercial experience developing ordinary software, I have seen null reference errors often enough, that I would like to address the problem in my own products and practices.

For years, Microsoft has invested in research designed to improve software quality. One of their efforts was the Spec# project. One of the most exciting developments in my opinion with the.net 4.0 framework, is the introduction of Microsoft code contracts, which is an outgrowth of the earlier work done by the Spec# research team.

Regarding your remark "the vast majority of errors in code are null reference exceptions", I believe it is the qualifier "the vast majority" that will cause some disagreements. The phrase "Vast majority" suggests that perhaps 70-90% of faults have a null reference exception as the root cause. This seems far too high to me. I prefer to quote from the research of the Microsoft Spec#. In their article The Spec# programming system: An overview, by Mike Barnett, K. Rustan M. Leino, and Wolfram Schulte. In CASSIS 2004, LNCS vol. 3362, Springer, 2004, they wrote

1.0 Non-Null Types Many errors in modern programs manifest themselves as null-dereference errors, suggesting the importance of a programming language providing the ability to discriminate between expressions that may evaluate to null and those that are sure not to (for some experimental evidence, see [24, 22]). In fact, we would like to eradicate all null dereference errors.

This is a likely source for people at Microsoft who are familiar with this research. This article is available at the Spec# site.

I've copied references 22 and 24 below, and included the ISBN for your convenience.

• Manuel Fahndrich and K. Rustan M. Leino. Declaring and checking non-null types in an object-oriented language. In Proceedings of the 2003 ACM Conference on Object-Oriented Programming, Systems, Languages, and Applications, OOPSLA 2003, volume 38, number 11 in SIGPLAN Notices, pages 302–312. ACM, November 2003. isbn = {1-58113-712-5},

• Cormac Flanagan, K. Rustan M. Leino, Mark Lillibridge, Greg Nelson, James B. Saxe, and Raymie Stata. Extended static checking for Java. In Proceedings of the 2002 ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI), volume 37, number 5 in SIGPLAN Notices, pages 234–245. ACM, May 2002.

I reviewed these references. The first reference indicates some experiments they did reviewing their own code for possible null reference defects. Not only did they find several, but in many cases, the identification of a potential null reference indicated a broader problem with the design.

The second reference does not provide any specific evidence for the assertion that null reference errors are problem. But the authors do state that in their experience, these null reference errors are significant source of software defects. The paper then proceeds to explain how they try to eradicate these defects.

I also remembered seeing something about this in an announcement from ISE on a recent release of Eiffel. They refer to this issue as "void safety", and like so many things inspired or developed by Dr. Bertrand Meyer, they have an eloquent and educational description of the problem and how they go about preventing it in their language and tools. I recommend you read their article http://doc.eiffel.com/book/method/void-safety-background-definition-and-tools to learn more.

If you want to learn more about Microsoft code contracts, there are tons of articles that have arisen recently. You can also check my blog at http: SLASH SLASH codecontracts.info which is primarily devoted to conversations about software quality through the use of programming with contracts.

这篇关于避免引用异常引用的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！