Обязательно ли использовать try/else?

Question

[zlodiak]

Скажите пожалуйста какая из двух следующих записей более корректна?

1:

try:
    html = requests.get(url, headers=self.headers)
    return html.text
except Exception as e:
    print('Root page parse is failed', e)

2:

try:
    html = requests.get(url, headers=self.headers)
except Exception as e:
    print('Root page parse is failed', e)
else:
    return html.text

PEP8 по этому поводу ничего не говорит. В нём есть похожий пример, но он раскрывает другую идею:

Yes:

try:
    value = collection[key]
except KeyError:
    return key_not_found(key)
else:
    return handle_value(value)
No:

try:
    # Too broad!
    return handle_value(collection[key])
except KeyError:
    # Will also catch KeyError raised by handle_value()
    return key_not_found(key)

Answer 1

[Nurbol Suleimenov]

Ваши варианты не ошибочны, но есть несколько моментов для осмысления.
Судя по наличию return, у Вас функция возвращает текст. Какое поведение Вы предусмотрели
в случае неудачного завершения операции requests.get? И на каком уровне Вы намерены
обрабатывать ошибки. Никто не может сказать Вам, как правильно, пока не узнает контекст
Вашей задачи. Может Вы выберите стратегию: "падать как можно раньше" и вызвав панику
завершите приложение, запишите в лог и перейдете к следующему url или что то еще.

Предложу Вам третьи вариант:

try:
    html = requests.get(url, headers=self.headers)
except Exception as e:
    print('Root page parse is failed', e)
    # Ваши инструкции для ошибочной ситуации
return html.text

Первый вариант плох тем, что блоке для отлова стоит return, который не может
вызвать в данном случае исключение. Второй тем, что используете else
без необходимости. Явное лучше неявного. Использование Else как многие
эксперты замечают в целом вредная практика. И в добавок, если функция
возвращает значение, то прописывайте return в основном теле, а не в
ветвлении. В будущем откроете для себя аннотирование типов, и начнете
использовать статические анализаторы.

P.S. Если будет время, то виды исключении лучше обрабатывать явно, а не
ловить их все в один блок. Так можно прописать несколько стратегии для
разных случаев сбоя.

Comments

[Andy_U]

Ваш вариант неработоспособен. Если в requests.get будет сгенерировано исключение, то html ничего не присвоится, и следующее исключение произойдет в return.

[Nurbol Suleimenov]

Andy_U, если Вы про то, что в блоке except нет присвоения html или выхода(sys.exit(1)), то значит, что Вы не внимательно читали мой ответ. Мой комментарий был не для пропуска, а для замены его соответсвующими инструкциями.

# Ваши инструкции для ошибочной ситуации

Это как раз то место, о котором я писал. Где следует разрешать проблему. Как я и писал, абсолютно верного ответа для ситуации автора вопроса не представляется выбрать. Все из за того, что вопрос задан отдельно от его случая использования. В этом блоке допустимы различные варианты разрешения проблемы:

• sys.exit(1). Выход в ОС с ошибкой. Больше годится для утилит, ...
  
• return "". Можно вернуть None или вызвать свой тип исключения. raise MyException к примеру. Это случай, к примеру для пропуска этого случая через обработку ошибки на уровне в котором вызывают эту функцию
  
• Не исключаю, что кому то в самый раз будет возвращать значение по умолчанию. return "{\"value\": \"\", \"count\": 0}"Если нужно получать всегда какой нибудь ответ
  
• Еще масса вариантов
  

Я не стал подробно расписывать все это в ответе, но все же zlodiak отметил ответ решением. Думаю, ему стало понятно о чем я писал. Тем не менее, вот у меня появилось время, и я подробно раскрыл некоторые случаи о которых писал

[zlodiak]

Nurbol Suleimenov, да, вы правы - я неудачно сформулировал вопрос. Но вы всё разложили по полочкам, если так можно сказать

[Andy_U]

Nurbol Suleimenov, Давайте посмотрим на ваши варианты обработки ошибки:

sys.exit(1). Выход в ОС с ошибкой. Больше годится для утилит, ...

Проще выкинуть try/except из кода. Эффект тот же, а код короче.

return "".

И как такой ответ отличить от попадания на пустую страницу?

Можно вернуть None

А потом разбираться с типом возврата из функции? Без этого никак. Т.е. двойная работа.

или вызвать свой тип исключения. raise MyException к примеру. Это случай, к примеру для пропуска этого случая через обработку ошибки на уровне в котором вызывают эту функцию

А почему просто не ловить то исключение, которое генерируется в requests.get()?

Поймите, ловить исключение нужно там, где используется результат работы функции. А кто же его знает, что автору надо. Если это разовый вызов, одно решение, если, например программа в цикле собирает данные с разных страничек, например, в в список, то вот именно list.append(f(url)) и нужно оборачивать в try/except...

[Nurbol Suleimenov]

А кто же его знает, что автору надо. Если это разовый вызов, одно решение, если, например программа в цикле собирает данные с разных страничек, например, в в список, то вот именно list.append(f(url)) и нужно оборачивать в try/except...

Об этом, как раз я и писал.

Я не собираюсь оспаривать, что Вы написали. Не забывайте, что платформа создана для того,
чтобы задавать вопросы и получать ответы. Если считаете мой ответ не верным, пишите свой.
Не исключаю, что он будет лучше чем мой. Автор вопроса получит более квалифицированный
ответ, и все будут довольны. Пусть решает zlodiak или пользователи платформы.

Вы не считаете, что ветка растет спор ради спора. Это я о нас с Вами. На этом заканчиваю, Вы
можете поступать как хотите.

Answer 2

[Andy_U]

Оба вариант некорректны. Протестируйте и увидите.

Comments

[zlodiak]

Andy_U проверил оба варианта - работают...

[Andy_U]

zlodiak, Судя по наличию return, речь идет о внутренности некой функции. И в обеих ваших вариантах функция будет возвращать None после обработки исключения. Т.е. снаружи фиг поймешь, что произошло. Или просто еще одно исключение сгенерируется, когда вы станете работать с None, как со строкой. А вот в примерах из документации return присутствует в обеих ветках.

[Andy_U]

Nurbol Suleimenov, Я писал Вам... Если уж приводите код для человека, который явно еще не профессионал, так уж приводите работающий пример. Хоть как-то. Без доработок. А комментарии к Вашим вариантам выше.

Answer 3

[h0w4rd]

Первый вариант конечно. Второй не будет работать даже.

Comments

[Nurbol Suleimenov]

Вы должно быть спутали else с finally. Второй вариант не ошибочен.