LBYL против EAFP в Java?

Лично я считаю, что это подтверждено условностями, 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 влечет за собой некоторые накладные расходы, даже если исключение не генерируется.

Если вы обращаетесь к файлам, EAFP более надежен, чем LBYL, потому что операции, задействованные в LBYL, не являются атомарными, и файловая система может измениться между временем, когда вы смотрите, и временем, когда вы прыгаете. Собственно, стандартное название - TOCTOU - Time of Check, Time of Use; ошибки, вызванные неточной проверкой, являются ошибками TOCTOU.

Рассмотрите возможность создания временного файла, который должен иметь уникальное имя. Лучший способ узнать, существует ли выбранное имя файла - это попытаться его создать, убедившись, что вы используете параметры, гарантирующие, что ваша операция завершится ошибкой, если файл уже существует (в терминах POSIX / Unix флаг O_EXCL равен open()). Если вы попытаетесь проверить, существует ли уже файл (вероятно, с помощью access()), то между моментом, когда будет сказано «Нет», и временем, когда вы попытаетесь создать файл, кто-то или что-то еще могло создать файл.

И наоборот, предположим, что вы пытаетесь прочитать существующий файл. Ваша проверка того, что файл существует (LBYL), может сказать «он есть», но когда вы действительно открываете его, вы обнаруживаете, что «его там нет».

В обоих случаях вы должны проверить последнюю операцию - и LBYL автоматически не помог.

(Если вы возитесь с программами SUID или SGID, access() задает другой вопрос; он может иметь отношение к LBYL, но код все равно должен учитывать возможность сбоя.)

Помимо относительной стоимости исключений в Python и Java, имейте в виду, что между ними существует разница в философии / подходе. Java пытается быть очень строгим в отношении типов (и всего остального), требуя явных, подробных объявлений сигнатур классов / методов. Предполагается, что в любой момент вы должны точно знать, какой тип объекта вы используете и на что он способен. Напротив, «утиная типизация» в Python означает, что вы не знаете наверняка (и не должны заботиться) о том, какой тип манифеста является объектом, вам нужно только позаботиться о том, чтобы он крякал, когда вы его об этом просите. В такой снисходительной среде единственное разумное отношение - предполагать, что что-то сработает, но быть готовым иметь дело с последствиями, если они этого не сделают. Естественная ограниченность Java не подходит для такого случайного подхода. (Это не призвано принижать какой-либо подход или язык, а скорее сказать, что такое отношение является частью идиомы каждого языка, и копирование идиом между разными языками часто может привести к неловкости и плохому общению ...)

Исключения обрабатываются в Python более эффективно, чем в Java, что, по крайней мере, частично, почему вы видите эту конструкцию в Python. В Java более неэффективно (с точки зрения производительности) использовать исключения таким образом.

Рассмотрим эти фрагменты кода:

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; при вызове со строкой «²³????₅» он выдаст ошибку, а не вернет значение по умолчанию.

Позднее, использование EAFTP, по определению приводит к правильной обработке. Возможности для поведенческого несоответствия отсутствуют, потому что код, которому требуется требование, является кодом, который утверждает это требование.

Использование LBYL означает использование внутренней логики и ее копирование на каждый сайт вызова. Вместо того, чтобы иметь одну каноническую кодировку ваших требований, у вас есть бесплатный шанс испортить каждый раз, когда вы вызываете функцию.

Стоит отметить, что EAFTP не касается исключений, и особенно код Java не должен использовать исключения повсеместно. Речь идет о том, чтобы дать правильную работу правильному блоку кода. Например, использование Optional возвращаемых значений является совершенно правильным способом написания кода EAFTP и гораздо более эффективным для обеспечения правильности, чем LBYL.