После запроса в базу вы получаете список rows, который иногда бывает пустым. Код rows[0] падает с IndexError. Какой вариант лучше, если пустой результат — ожидаемый кейс?
AОбернуть всё в
try и ловить except Exception:.BСделать проверку
if rows: перед rows[0], иначе вернуть None или обработать пустой кейс отдельно.CПисать
rows[0] и игнорировать IndexError, потому что он «не важен».DСделать
raise IndexError('no rows'), чтобы всегда падало.Правильный ответ. Если пустой список возможен по данным, лучше явная проверка, чем ловля ошибок «на всякий случай».
Разбор
Сравнение подходов важно: проверка условия делает код понятнее, а исключения — инструмент для неожиданных ситуаций. Если пустой результат нормален, if rows: заранее описывает логику, помогает читателю кода и убирает лишние исключения из потока. Ловить Exception слишком широко — риск скрыть реальные баги.
Проверь себя · 1/3разбор после ответа
Вы обрабатываете события, где поле
utm_source может отсутствовать, и это нормально. Какой подход обычно лучше, чем ловить KeyError ради значения по умолчанию?Ещё вопросы по теме «Исключения и отладка»
- В обработчике данных вы используете конструкцию `try`/`except`/`finally`. Внутри `try` происходит ошибка, она поймана в `except`. Что произойдёт с кодом в `finally`?
- Вы парсите событие в словарь `event`. Что произойдёт при обращении `event["currency"]`, если ключа `currency` в словаре нет?
- В отчёте вы считаете сумму и случайно складываете число и строку: `total + "10"`. Какое исключение наиболее вероятно?
- Скрипт получает список строк, но иногда он короче ожидаемого. Что произойдёт при обращении `rows[3]`, если в списке всего 3 элемента?
- Вы пишете функцию, которая внутри `try` делает `return`, а в `finally` закрывает ресурс (например, файл или соединение). Что произойдёт с кодом в `finally` при `return` из `try`?
- Все вопросы по «Исключения и отладка» →