Хорошая практика использования try-except-else в Python?

В чем причина существования try-except-else?

A try позволяет обрабатывать ожидаемую ошибку. Блок except должен обрабатывать только исключения, которые вы готовы обработать. Если вы справляетесь с непредвиденной ошибкой, ваш код может ошибиться и скрыть ошибки.

Предложение else будет выполняться, если ошибок не было, и, не выполняя этот код в блоке try, вы избегаете обнаружения неожиданной ошибки. Опять же, обнаружение неожиданной ошибки может скрыть ошибки.

Пример

Например:

try:
    try_this(whatever)
except SomeException as the_exception:
    handle(the_exception)
else: 
    return something

В пакете "try, except" есть два необязательных предложения: else и finally. Так что это на самом деле try-except-else-finally.

'else' будет оцениваться только в случае отсутствия исключения из блока try. Это позволяет нам упростить более сложный код ниже:

no_error = None
try:
    try_this(whatever)
    no_error = True
except SomeException as the_exception:
    handle(the_exception)
if no_error:
    return something

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

finally

finally будет выполняться независимо от того, что даже если другая строка оценивается с помощью оператора return.

Сбой с псевдокодом

Это может помочь сломать это в наименьшей возможной форме, демонстрирующей все функции, с комментариями. Предположим, что это синтаксически корректно (но не выполняется, если имена не определены). Псевдокод находится в функции.

Например:

try:
    try_this(whatever) 
except SomeException as the_exception:
    handle_SomeException(the_exception)
    # Handle a instance of SomeException or a subclass of it.
except Exception as the_exception:
    generic_handle(the_exception)
    # Handle any other exception that inherits from Exception
    # - doesn't include GeneratorExit, KeyboardInterrupt, SystemExit
    # Avoid bare `except:`
else: # there was no exception whatsoever
    return something() 
    # if no exception, the "something()" gets evaluated, 
    # but the return will not be executed due to the return in the 
    # finally block below.
finally:
    # this block will execute no matter what, even if no exception,
    # after "something" is eval'd but before that value is returned
    # but even if there is an exception.
    # a return here will hijack the return functionality. e.g.:
    return True # hijacks the return in the else clause above

Верно, что мы могли бы включить код в блок else в блок try вместо этого, где он будет работать, если не было исключений, но что, если этот код сам вызывает исключение того типа, re ловли? Оставить его в блоке try скрыть эту ошибку.

Мы хотим минимизировать строки кода в блоке try, чтобы избежать улавливания исключений, которых мы не ожидали, по принципу, что если наш код выходит из строя, мы хотим, чтобы он громко рухнул. Это лучшая практика.

Я понимаю, что исключения не являются ошибками

В Python большинство исключений - ошибки.

Мы можем просмотреть иерархию исключений с помощью pydoc. Например, в Python 2:

$ python -m pydoc exceptions

или Python 3:

$ python -m pydoc builtins

Дайте нам иерархию. Мы видим, что большинство типов Exception являются ошибками, хотя Python использует некоторые из них для таких вещей, как end for loop (StopIteration). Это иерархия Python 3:

BaseException
    Exception
        ArithmeticError
            FloatingPointError
            OverflowError
            ZeroDivisionError
        AssertionError
        AttributeError
        BufferError
        EOFError
        ImportError
            ModuleNotFoundError
        LookupError
            IndexError
            KeyError
        MemoryError
        NameError
            UnboundLocalError
        OSError
            BlockingIOError
            ChildProcessError
            ConnectionError
                BrokenPipeError
                ConnectionAbortedError
                ConnectionRefusedError
                ConnectionResetError
            FileExistsError
            FileNotFoundError
            InterruptedError
            IsADirectoryError
            NotADirectoryError
            PermissionError
            ProcessLookupError
            TimeoutError
        ReferenceError
        RuntimeError
            NotImplementedError
            RecursionError
        StopAsyncIteration
        StopIteration
        SyntaxError
            IndentationError
                TabError
        SystemError
        TypeError
        ValueError
            UnicodeError
                UnicodeDecodeError
                UnicodeEncodeError
                UnicodeTranslateError
        Warning
            BytesWarning
            DeprecationWarning
            FutureWarning
            ImportWarning
            PendingDeprecationWarning
            ResourceWarning
            RuntimeWarning
            SyntaxWarning
            UnicodeWarning
            UserWarning
    GeneratorExit
    KeyboardInterrupt
    SystemExit

Python не соглашается с идеей, что исключения должны использоваться только для исключительных случаев, на самом деле идиома 'просить прощения, а не разрешения'. Это означает, что использование исключений в качестве обычной части вашего управления потоком вполне приемлемо и, по сути, рекомендуется.

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

Представьте, что у вас есть ситуация, когда вы берете какой-то пользовательский ввод, который нужно обработать, но имеете по умолчанию, который уже обработан. Структура try: ... except: ... else: ... обеспечивает очень читаемый код:

try:
   raw_value = int(input())
except ValueError:
   value = some_processed_value
else: # no error occured
   value = process_value(raw_value)

Сравните с тем, как он может работать на других языках:

raw_value = input()
if valid_number(raw_value):
    value = process_value(int(raw_value))
else:
    value = some_processed_value

Обратите внимание на преимущества. Нет необходимости проверять, что значение действительно, и разобрать его отдельно, они выполняются один раз. Код также следует за более логичной прогрессией, сначала начинается основной путь кода, а затем "если он не работает, сделайте это".

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

Является ли хорошей практикой использование try-except-else в python?

Ответ на этот вопрос заключается в том, что он зависит от контекста. Если вы это сделаете:

d = dict()
try:
    item = d['item']
except KeyError:
    item = 'default'

Это демонстрирует, что вы не очень хорошо знаете Python. Эта функциональность инкапсулирована в метод dict.get:

item = d.get('item', 'default')

Блок try/except - гораздо более визуально загроможденный и многословный способ записи того, что может эффективно выполняться в одной строке с помощью атомного метода. Существуют и другие случаи, когда это верно.

Однако это не означает, что мы должны избегать обработки исключений. В некоторых случаях предпочтительно избегать условий гонки. Не проверяйте, существует ли файл, просто попытайтесь его открыть и поймайте соответствующий IOError. Ради простоты и удобочитаемости попробуйте инкапсулировать это или скомпенсировать его как можно скорее.

Прочитайте Zen of Python, понимая, что есть принципы, которые находятся в напряжении, и будьте осторожны с догмой, которая слишком сильно зависит от любого из заявлений в ней.

Вы должны быть осторожны с использованием блока finally, поскольку это не то же самое, что использовать блок else в try, кроме. Блок finally будет запускаться независимо от результата попытки, кроме.

In [10]: dict_ = {"a": 1}

In [11]: try:
   ....:     dict_["b"]
   ....: except KeyError:
   ....:     pass
   ....: finally:
   ....:     print "something"
   ....:     
something

Как все отметили, используя блок else, ваш код становится более читаемым и работает только тогда, когда исключение не выбрано

In [14]: try:
             dict_["b"]
         except KeyError:
             pass
         else:
             print "something"
   ....:

Всякий раз, когда вы видите это:

try:
    y = 1 / x
except ZeroDivisionError:
    pass
else:
    return y

Или даже это:

try:
    return 1 / x
except ZeroDivisionError:
    return None

Рассмотрим это вместо:

import contextlib
with contextlib.suppress(ZeroDivisionError):
    return 1 / x

Это мой простой фрагмент о том, как понять блок try-except-else-finally в Python:

def div(a, b):
    try:
        a/b
    except ZeroDivisionError:
        print("Zero Division Error detected")
    else:
        print("No Zero Division Error")
    finally:
        print("Finally the division of %d/%d is done" % (a, b))

Попробуйте div 1/1:

div(1, 1)
No error
Finally the division of 1/1 is done

Попробуйте div 1/0

div(1, 0)
Zero Division Error detected
Finally the division of 1/0 is done

ОП, ВЫ ПРАВИЛЬНО. Остальное после try/except в Python является уродливым. это приводит к другому объекту управления потоком, где нет необходимости:

try:
    x = blah()
except:
    print "failed at blah()"
else:
    print "just succeeded with blah"

Полностью явный эквивалент:

try:
    x = blah()
    print "just succeeded with blah"
except:
    print "failed at blah()"

Это намного яснее, чем предложение else. Остальное после try/except не часто записывается, поэтому требуется некоторое время, чтобы понять, что подразумевается.

Просто потому, что вы МОЖЕТЕ сделать что-то, не означает, что вы ДОЛЖНЫ что-то сделать.

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

Просто мои 5 центов здесь. Я должен зайти позади и очистить много кода, написанного 1-м годом от разработчиков колледжа, которые считают, что они умны и хотят писать код в какой-то uber-tight, uber-efficient, когда это просто заставляет чтобы попытаться прочитать/изменить позже. Я голосую за удобочитаемость каждый день и дважды по воскресеньям.