Java 中的 LBYL 与 EAFP？

Question

我最近正在自学 Python，并发现了有关代码执行前错误检查的 LBYL/EAFP 习惯用法。 在Python中，似乎公认的风格是EAFP，并且它似乎与该语言配合得很好。

LBYL（L在Y或Leap之前B em>）：

def safe_divide_1(x, y):
    if y == 0:
        print "Divide-by-0 attempt detected"
        return None
    else:
        return x/y

EAFP（A更容易Ask Forgiveness 比Permission)：

def safe_divide_2(x, y):
    try:
        return x/y
    except ZeroDivisionError:  
        print "Divide-by-0 attempt detected"
        return None

我的问题是这样的：我从未听说过使用 EAFP 作为主要数据验证结构，来自 Java 和 C++ 背景。 在 Java 中使用 EAFP 是否明智？ 或者异常的开销是否太大？ 我知道只有在实际抛出异常时才会有开销，所以我不确定为什么不使用 EAFP 的更简单方法。 这只是偏好吗？

Answer 1

如果你正在访问文件，EAFP比LBYL更可靠，因为LBYL涉及的操作不是原子的，并且文件系统可能在你查看的时间和你跳跃的时间之间发生变化。 实际上，标准名称是 TOCTOU - Time of Check、Time of Use； 由于检查不准确而导致的错误是TOCTOU错误。

考虑创建一个必须具有唯一名称的临时文件。 查明所选文件名是否存在的最佳方法是尝试创建它 - 确保使用选项来确保如果文件已经存在则操作失败（在 POSIX/Unix 术语中，O_EXCL 标志为 打开（））。 如果您尝试测试文件是否已存在（可能使用access()），那么在显示“否”的时间和您尝试创建文件的时间之间，某人或其他东西可能会已创建该文件。

相反，假设您尝试读取现有文件。 您检查文件是否存在（LBYL）可能会说“它在那里”，但当您实际打开它时，您会发现“它不在那里”。

在这两种情况下，您都必须检查最终操作 - 并且 LBYL 不会自动提供帮助。

（如果您正在搞乱 SUID 或 SGID 程序，access() 会提出不同的问题；它可能与 LBYL 相关，但代码仍然必须考虑失败的可能性。）

Answer 2

除了 Python 和 Java 中异常的相对成本之外，请记住它们之间的理念/态度也存在差异。 Java 试图对类型（以及其他一切）非常严格，要求对类/方法签名进行显式、详细的声明。 它假设您在任何时候都应该确切地知道您正在使用什么类型的对象以及它能够做什么。 相比之下，Python 的“鸭子类型”意味着你不确定（也不应该关心）对象的明显类型是什么，你只需要关心当你要求它时它会嘎嘎叫。 在这种宽容的环境中，唯一理智的态度就是假设事情会奏效，但如果不奏效，就要准备好应对后果。 Java 的天然限制性与这种随意的方法不太相符。 （这并不是要贬低方法或语言，而是说这些态度是每种语言习语的一部分，在不同语言之间复制习语往往会导致尴尬和沟通不良......）

Answer 3

Python 中的异常处理比 Java 中的处理效率更高，这至少是您在 Python 中看到这种构造的部分原因。 在 Java 中，以这种方式使用异常的效率较低（就性能而言）。

Answer 4

考虑这些代码片段：

def int_or_default(x, default=0):
    if x.isdigit():
        return int(x)
    else:
        return default

def int_or_default(x, default=0):
    try:
        return int(x)
    except ValueError:
        return default

它们看起来都是正确的，对吧？ 但其中之一不是。

前者使用 LBYL，但由于 isdigit 和 isdecimal 之间的细微差别而失败； 当使用字符串“①²³

Answer 5

就我个人而言，我认为这是有惯例支持的，EAFP 从来都不是一个好方法。
您可以将其视为与以下内容等效的内容：

if (o != null)
    o.doSomething();
else
    // handle

与以下内容相反：

try {
    o.doSomething()
}
catch (NullPointerException npe) { 
    // handle
}

此外，请考虑以下内容：

if (a != null)
    if (b != null)
        if (c != null)
            a.getB().getC().doSomething();
        else
            // handle c null
    else
        // handle b null
else
    // handle a null

这可能看起来不太优雅（是的，这是一个粗略的示例 - 请耐心等待），但它为您提供了更大的粒度处理错误，而不是将其全部包装在 try-catch 中以获取 NullPointerException，然后尝试找出在哪里以及为什么得到它。

我的看法是，除非极少数情况，否则永远不应该使用 EAFP。 另外，既然您提出了这个问题：是的，即使没有抛出异常，try-catch 块也会产生一些开销。