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