Исключения и контекстные менеджеры в Python

Проверьте себя

Пять вопросов из банка по этой подтеме. Всего их 19, остальные разбираются в тренажёре.

1. #errors_context1 / 5
   В конструкции try / except / else / finally — что и когда выполняется?

   A)else выполняется, если исключения не было; finally — всегда, и при ошибке, и без неё, например для освобождения ресурса

   B)Else выполняется только при возникновении исключения, а finally — наоборот, лишь если исключения в блоке try не случилось

   C)И else, и finally выполняются исключительно тогда, когда внутри блока try было выброшено хотя бы одно исключение

   D)Finally выполняется лишь в случае, когда исключение не было перехвачено ни одним из блоков except, стоящих выше по коду

   показать ответ и разбор

   +A)else выполняется, если исключения не было; finally — всегда, и при ошибке, и без неё, например для освобождения ресурса

   // разбор: try — защищаемый код; except — обработка конкретных ошибок; else — выполняется только если try прошёл без исключений (отделяет рискованную часть от продолжения); finally — выполняется всегда, при любом исходе, в том числе при return внутри try, и служит для гарантированного освобождения ресурсов. Это и делает finally надёжным местом для очистки.

2. #errors_context2 / 5
   Чем плохо писать голый except: без указания типа исключения?

   A)Ничем не плохо: это рекомендуемый и самый безопасный способ обработки, ловящий ровно нужные ошибки максимально точечно

   B)Он ловит вообще всё подряд, включая KeyboardInterrupt и SystemExit, и прячет опечатки и баги — сужай до конкретных типов

   C)Голый except не рекомендуется в Python и приводит к синтаксической ошибке ещё на этапе разбора кода

   D)Он замедляет программу в несколько раз, потому что заставляет интерпретатор проверять каждый её оператор на наличие ошибки

   показать ответ и разбор

   +B)Он ловит вообще всё подряд, включая KeyboardInterrupt и SystemExit, и прячет опечатки и баги — сужай до конкретных типов

   // разбор: Голый except (и почти столь же грубый except Exception) перехватывает всё подряд, включая системные KeyboardInterrupt и SystemExit, а также незамеченные баги вроде опечаток в именах, — программа молча продолжает работу в неверном состоянии. Ловят конкретные ожидаемые типы (except ValueError), а неожиданное пусть падает громко, с трейсбеком.

3. #errors_context3 / 5
   Что означает питонический принцип EAFP по сравнению с LBYL?

   A)EAFP требует заранее проверить все условия длинной цепочкой if, прежде чем выполнять потенциально опасное действие

   B)EAFP и LBYL — это просто два названия одного и того же подхода, разницы между ними в реальном коде совершенно никакой нет

   C)EAFP предписывает не пользоваться исключениями, заменяя их возвращаемыми кодами ошибок из функций

   D)EAFP («проще просить прощения») — делать действие в try/except; LBYL — проверять условия заранее через if. В Python EAFP часто чище

   показать ответ и разбор

   +D)EAFP («проще просить прощения») — делать действие в try/except; LBYL — проверять условия заранее через if. В Python EAFP часто чище

   // разбор: LBYL (look before you leap) проверяет условия заранее: if key in d: use(d[key]). EAFP (easier to ask forgiveness) просто делает и ловит исключение: try: use(d[key]) except KeyError: .... EAFP часто короче и свободен от гонки (между проверкой и действием состояние могло измениться), поэтому в Python его нередко предпочитают.

4. #errors_context4 / 5
   Зачем заводить свои классы исключений вместо raise Exception('...')?

   A)Свои исключения обязательны: без них интерпретатор Python запрещает использовать конструкцию raise где-либо в коде программы

   B)Ради скорости: пользовательские классы исключений обрабатываются интерпретатором быстрее встроенных типов

   C)Чтобы вызывающий ловил их точечно (except MyError) и отличал ожидаемые доменные ошибки от прочих — тип несёт смысл

   D)Свои классы исключений автоматически логируют себя в файл и шлют уведомление разработчику вообще без какой-либо настройки

   показать ответ и разбор

   +C)Чтобы вызывающий ловил их точечно (except MyError) и отличал ожидаемые доменные ошибки от прочих — тип несёт смысл

   // разбор: Свой тип исключения (class OrderNotFound(Exception)) позволяет вызывающему поймать именно его — except OrderNotFound — не хватая заодно все прочие ошибки, и несёт доменный смысл. raise Exception слишком широк: отличить такую ошибку можно лишь по тексту, что хрупко. Иерархия своих исключений делает обработку точной и читаемой, а обработчики — устойчивыми.

5. #errors_context5 / 5
   Блок except перехватывает ошибку, пишет её в лог и делает pass. Чем это опасно?

   A)Ничем: перехватить ошибку, залогировать её и продолжить выполнение — правильная и безопасная практика в проде

   B)Проглатывание ошибки: программа идёт дальше в неверном состоянии, баг замаскирован. Обрабатывай конкретное или пробрасывай (raise)

   C)Опасность лишь в том, что запись в лог заметно замедляет программу, поэтому логирование ошибки из блока лучше вообще убрать

   D)Pass в блоке except вызывает бесконечный цикл повторной обработки той же ошибки, пока у процесса не закончится вся память

   показать ответ и разбор

   +B)Проглатывание ошибки: программа идёт дальше в неверном состоянии, баг замаскирован. Обрабатывай конкретное или пробрасывай (raise)

   // разбор: Перехват широкого исключения с последующим pass или continue проглатывает проблему: функция «как бы отработала», хотя данные или состояние испорчены, а настоящая причина всплывёт позже и далеко от источника. Ловят конкретный ожидаемый тип и осмысленно его обрабатывают; неизвестное пробрасывают дальше (re-raise) или дают упасть, чтобы увидеть трейсбек.