[ 这是 Best Practice: Should functions return null or an empty object? 的结果但我试图非常笼统。 ]
在我见过的许多遗留(嗯...生产)C++ 代码中，倾向于编写很多 NULL(或类似) 检查以测试指针。其中许多是在发布周期快结束时添加 NULL 时添加的——检查可以快速修复由指针取消引用引起的崩溃——并且没有太多时间进行调查.
为了解决这个问题，我开始编写使用 (const) 引用参数的代码，而不是(更)更常见的传递指针技术。没有指针，不希望检查 NULL(忽略实际具有空引用的极端情况)。
在 C# 中，存在相同的 C++“问题”:希望根据 null (ArgumentNullException) 检查每个未知引用并快速修复 NullReferenceExceptions 通过添加 null 检查。
在我看来，防止这种情况的一种方法是首先通过使用空对象 (String.Empty, EventArgs.Empty) 来避免空对象.另一种方法是抛出异常而不是返回 null。
我刚开始学习 F#，但在那个环境中似乎空对象要少得多。所以也许你真的不需要有很多 null 引用漂浮在周围？
我在这里叫错树了吗？
最佳答案
仅仅为了避免 NullReferenceException 而传递非 null 是在用一个更微妙、更难以解决的问题(“因为它是空的”)来交换一个简单、易于解决的问题调试问题(“堆栈中的一些调用未按预期运行，因为它更早地获得了一些没有有意义信息但不为空的对象”)。
NullReferenceException 是一个奇妙的事情!它失败得厉害、响亮、快速，而且几乎总是快速且容易识别和修复。这是我最喜欢的异常(exception)，因为我知道当我看到它时，我的任务只需要大约 2 分钟。将此与试图描述必须重现并追溯到源头的奇怪行为的令人困惑的 QA 或客户报告进行对比。呸。
这一切都取决于您作为一个方法或一段代码，可以合理地推断出调用您的代码。如果您收到一个空引用，并且您可以合理地推断出调用者可能通过空值表示的含义(例如，可能是一个空集合？)那么您绝对应该只处理空值。但是，如果您无法合理地推断出如何处理 null 或调用者通过 null 表示什么(例如，调用代码告诉您打开文件并将位置指定为 null)，您应该抛出一个 ArgumentNullException.
在每个“网关”点都保持这样的正确编码实践——代码中功能的逻辑界限——NullReferenceExceptions应该少得多。
关于c# - 空对象与空对象，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1628434/