Контекстный менеджер Python: как проверить закрытие файла после исключения

Если нужен короткий ответ, проверка обычно выглядит так: открыть файл через with, внутри блока намеренно или случайно получить исключение, перехватить его снаружи и затем проверить у сохраненного файлового объекта свойство closed. Если блок with уже завершился, а файл действительно был открыт, ожидаемое состояние — True.

Но в реальном коде важна не только одна строка с f.closed. Нужно понимать, когда проверять состояние, что делать, если файл не открылся вообще, и как превратить разовую ручную проверку в повторяемый тест. Ниже разберем именно эту задачу: управление временем жизни ресурса и проверку закрытия файла после ошибки внутри with.

Почему вопрос возникает именно при исключениях

Файл — это не просто переменная со строками, а внешний ресурс. Пока ресурс открыт, интерпретатор и операционная система считают его занятым: у процесса есть дескриптор, у файла есть состояние чтения или записи, а часть данных может еще не быть окончательно сброшена. Поэтому здесь важен не только результат вычислений, но и момент освобождения ресурса.

Проблема появляется, когда код выходит из обычной последовательности шагов. Если файл открыли вручную через open(), что-то сделали и в середине работы получили исключение, строка с close() может просто не выполниться. Из-за этого проверка «закрыт ли файл после ошибки» — не формальность, а способ убедиться, что аварийный путь не оставляет за собой открытые ресурсы.

Практически это означает простое правило: проверять нужно не то, была ли ошибка, а то, что произошло с ресурсом после ошибки. Исключение может быть ожидаемым и даже полезным для сигнализации о проблеме. Незакрытый файл — уже отдельная неисправность, которую лучше исключить конструкцией with.

Что именно делает with с файлом

Конструкция with оборачивает блок кода и вызывает код завершения при выходе из блока. Для файла это означает автоматическое закрытие, когда выполнение покидает блок: по обычному пути, по return или из-за исключения. Важно различать две вещи: with отвечает за завершение работы с ресурсом, а не обязательно за подавление самой ошибки.

Поэтому нормальная картина выглядит так: внутри блока случается исключение, блок завершается, файл закрывается, затем исключение либо поднимается дальше, либо перехватывается внешним except. И именно после выхода из with имеет смысл проверять состояние файла. Проверка внутри блока ничего не докажет: в этот момент ресурс еще используется и закономерно остается открытым.

• Что проверяет with: был ли завершен блок и вызван ли код очистки ресурса.
• Что with не обещает сам по себе: что ошибка исчезнет или что файл вообще успел открыться.
• Что надо учитывать в коде: если открытие файла сорвалось до входа в блок, проверять closed будет не у чего.

УЧЕБНЫЙ ПРИМЕР: как проверить закрытие файла после исключения

УЧЕБНЫЙ ПРИМЕР. Ниже условный сценарий для обычного Python 3 в консоли. Мы создаем небольшой файл, отдельно пробуем его открыть, затем заходим с ним в with, читаем первую строку и намеренно выбрасываем RuntimeError. После этого ловим исключение снаружи и возвращаем два проверяемых результата: было ли исключение нужного типа и закрылся ли файл.

from pathlib import Path


def verify_close_after_exception(path: Path):
    try:
        opened_file = path.open('r', encoding='utf-8')
    except OSError:
        return False, 'file was not opened'

    try:
        with opened_file as current_file:
            first_line = current_file.readline().strip()
            print(f'Прочитано: {first_line}')
            raise RuntimeError('Учебная ошибка внутри with')
    except RuntimeError as exc:
        return opened_file.closed, type(exc).__name__

    return False, 'no exception'


demo_path = Path('demo_context.txt')
demo_path.write_text('alpha\nbeta\n', encoding='utf-8')

closed_flag, exception_name = verify_close_after_exception(demo_path)
print(closed_flag)
print(exception_name)

Ожидаемый результат этого примера: на экран выводится первая строка файла, затем после перехвата ошибки переменная closed_flag получает значение True, а exception_name — строку RuntimeError. Это и есть полезная проверка: исключение произошло, но ресурс после выхода из with не остался висеть в открытом состоянии.

Здесь важно, что открытие вынесено в отдельный шаг до блока with. Поэтому функция действительно различает две ситуации. Первая — файл не открылся вовсе, и тогда она возвращает file was not opened. Вторая — файл открылся, ошибка произошла уже внутри with, и тогда проверка opened_file.closed относится именно к закрытию ресурса после исключения. Если позже понадобится разбирать еще и ошибки чтения, их лучше обрабатывать отдельно, а не смешивать с ошибкой открытия.

Как проверить результат не вручную, а повторяемо

Разовая печать True полезна для понимания механики, но в рабочем коде лучше иметь автопроверку. Для такой задачи удобно использовать pytest: он позволяет явно ожидать исключение и одновременно проверять состояние файла после выхода из блока. Тогда вы не просто один раз увидели правильный результат, а закрепили его тестом, который можно запускать после изменений в коде.

Ниже тот же учебный сценарий в виде теста. Здесь удобно то, что временный путь создает сам pytest, а проверка разбита на три шага: файл точно создан, исключение точно случилось, файл после этого точно закрыт.

import pytest


def test_file_is_closed_after_exception(tmp_path):
    path = tmp_path / 'demo.txt'
    path.write_text('alpha\nbeta\n', encoding='utf-8')

    file_obj = None

    with pytest.raises(RuntimeError):
        with path.open('r', encoding='utf-8') as current_file:
            file_obj = current_file
            current_file.readline()
            raise RuntimeError('boom')

    assert file_obj is not None
    assert file_obj.closed is True

Если нужен еще один уровень проверки, можно дополнительно удостовериться, что использовать закрытый файл уже нельзя. Но это скорее вспомогательный признак. Основной индикатор для вопроса из статьи — именно file_obj.closed is True. Попытка чтения после закрытия полезна как подтверждение поведения, а не как замена прямой проверки состояния.

Где чаще ошибаются при такой проверке

Первая частая ошибка — проверять closed слишком рано, прямо внутри блока with. Внутри блока файл должен быть открыт, иначе вы бы не могли с ним работать. Проверка должна происходить после выхода из блока, то есть после завершения контекста.

Вторая ошибка — путать обработку исключения с управлением ресурсом. Можно поймать ошибку в except и продолжить работу программы, но это само по себе не доказывает, что файл закрыт. Доказывает это либо with, либо корректно написанный try/finally, а в тесте — явная проверка closed.

Третья ошибка — не учитывать сценарий, в котором открытие файла не состоялось. Тогда обращаться к f.closed может быть просто не к чему. Поэтому в учебном примере открытие было вынесено отдельно: так проще проверить именно тот случай, когда ресурс успел появиться и затем был закрыт при выходе из with.

Для самостоятельной практики удобно сделать три шага: сначала воспроизвести минимальный пример из статьи, затем переписать его в тест с pytest, а потом изменить код так, чтобы исключение возникало в другом месте внутри блока. Если в каждом варианте после выхода из with вы стабильно получаете closed == True, значит, вы проверяете именно время жизни ресурса, а не случайное поведение конкретного фрагмента.

Если хотите добрать практику по этой теме, можно посмотреть внутреннюю карточку каталога курса по прикладному Python. По официальной программе школы там подтверждены темы работы с файловой системой и исключениями, контекстных менеджеров with open и базового тестирования через pytest. Это полезно именно для отработки связки «написал код — воспроизвел исключение — проверил результат».