防御性编程的局限性--承认应避免异常处理

Question

我读过防御性编程与异常处理？和if/else语句或例外，但没有一个包含与我正在寻找的内容相关的内容。

考虑到异常处理比精心设计代码和避免某些场景要花费更多的计算费用，我最近提出了以下问题:计算复杂性“阈值”是什么？

在我的例子中，我从外部中间件接收数据，有时字段为null。有两个案子我可以处理。

First

try {
    if (user.departNameEn.Equals(selectedUser) 
    || user.departNameFr.Equals(selectedUser) 
    || user.departNameDe.Equals(selectedUser)) {
        string fileName = AppDomain.CurrentDomain.BaseDirectory 
            + @"Images\Users\" + user.Id + user.ShortName + ".png";
        if (File.Exists(fileName))
        {
            retVal = fileName;
            return retVal;
        }
    }
}
catch (NullReferenceException e)
{
    continue;
}

第二

if (!string.IsNullOrEmpty(user.departNameEn)
    && !string.IsNullOrEmpty(user.departNameFr)
    && !string.IsNullOrEmpty(user.departNameDe)
    && !string.IsNullOrEmpty(user.Id)
    && !string.IsNullOrEmpty(user.ShortName)) {
    if (user.departNameEn.Equals(selectedUser) 
    || user.departNameFr.Equals(selectedUser) 
    || user.departNameDe.Equals(selectedUser)) {
        string fileName = AppDomain.CurrentDomain.BaseDirectory 
            + @"Images\Users\" + user.Id + user.ShortName + ".png";
        if (File.Exists(fileName))
        {
            retVal = fileName;
            return retVal;
        }
    }
}

直观地说，第一种方法比第二种方法更干净和优雅，但哪种方法在计算上更便宜？防御性编程的极限在哪里结束？

注意重复报告:正如我在介绍中所解释的，我已经阅读了异常处理与防御性编程的两个主要主题，但实际上我所问的是一些不同且非常具体的问题:当防御性编程在计算上比简化代码和添加单个try-catch语句更昂贵时？

Answer 1

我正在从外部中间件接收数据。

File.Exists

所以让我们来看看更大的情况。你有数据。这些数据被序列化了。那就发一条窃听器。然后反序列化。最后，您甚至可以根据这些数据访问文件系统。

从性能的角度来看如何处理这个问题是完全没有必要的，因为在您的场景中，计算能力实际上并不是瓶颈。这就像在想，是否应该让一个18轮的潜水员节食，以节省整体体重。

至于18轮:最好的解决办法是让司机做任何让他高兴和有动力驾驶他们的卡车的事情。无论朝哪个方向，一两磅都不重要。所以，做对程序员最好的事情吧。无论哪种方法更易读，用您的标准更容易理解代码，都是这里最好的解决方案。

以一种无关的方式：

user.departNameEn.Equals(selectedUser)

你叫Equals是有什么原因吗?或者这可能只是一个坏的Java习惯？

user?.departNameEn == selectedUser

这一行也是这样做的，不会抛出一边是null。唯一的“缺点”是，如果selectedUser是null，那么它也被认为是相等的，而不是像在行中那样抛出。

Answer 2

您期望空数据吗？

例外情况适用于特殊情况。

对于这种情况，最简单的经验法则是用逻辑(而不是例外)处理标准案例。

如果NULL是一个错误，例如表示传输失败，那么一个异常是合适的。但是，如果它指示一个可选字段是空的，那么这是一个“正常”用例，应该用逻辑进行检查。

问题中使用的示例意味着，如果缺少某些数据(这是意外的)，无效数据中的数据是无效的。

在这种情况下，我建议例外。

Answer 3

这取决于你给我们的更多的信息。如果某些字段为null，这意味着什么？这(1)完全可以接受，应该被解释为""的值吗？(2)不应该发生，但在实践中是常见的，而且容易解决问题？(3)可以处理，但只能处理用户的输入？(4)使处理记录不可能的缺陷？(5)严重故障的迹象，必须放弃整个导入(“停止并着火”)？

异常不仅在运行时处理成本更高，它们还以与标准控制结构不同的方式构造控制流。您可以使用if语句构建几乎任何可能的逻辑流，但是一旦从块中抛出异常，就没有合理的方法再次进入它，嵌套的catch子句几乎不可能以可读的方式编写。此外，在代码读者中编写try...catch会引起一定的期望；如果这些都不是真的，那么代码就更难理解了。这至少是选择如何处理不寻常情况的三个不同方面；其他方面可以应用，具体取决于您的代码正在处理的内容。