проверяя значения NA и игнорируя их [duplicate]

SELECT * FROM t1 ORDER BY rev DESC LIMIT 1;
50
задан Eric 12 July 2015 в 18:23
поделиться

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

Это может выглядеть намного менее изящным (и да, это грубый пример - медведь со мной), но он дает вам гораздо большую гранулярность в обработке ошибки, в отличие от обертывания всего этого в попытке попробовать, чтобы NullPointerException, а затем попытайтесь выяснить, где и почему вы его получили.

Как я вижу, EAFP никогда не должен использоваться, за исключением редких ситуаций. Кроме того, поскольку вы подняли вопрос: да, блок try-catch накладывает некоторые накладные расходы, даже если исключение не выбрано.

5
ответ дан Yuval Adam 26 August 2018 в 18:46
поделиться

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

44
ответ дан Jeff Shannon 26 August 2018 в 18:46
поделиться

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

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

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

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

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

112
ответ дан Jonathan Leffler 26 August 2018 в 18:46
поделиться

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

10
ответ дан mipadi 26 August 2018 в 18:46
поделиться

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

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; когда вызывается со строкой «①²³

2
ответ дан Veedrac 26 August 2018 в 18:46
поделиться
Другие вопросы по тегам:

Похожие вопросы: