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