Как заворачивать контекстный менеджер?

Question

[zlodiak]

Мне кажется, я погорячился:

def write_result(self, phone_num):
        try:
            with open(self.result_filename, 'a', encoding='utf-8') as f:
                f.write(phone_num + '\n')   
        except IOError as e:
            self.logger.write_into_error_log('Error write results for filename: ' + str(self.result_filename) + ' :: ' + str(e))
        except Exception as e:
            self.logger.write_into_error_log('Some error for: ' + str(self.result_filename) + ' :: ' + str(e))

Скажите пожалуйста, стоит ли так жёстко заворачивать в блок try/except операцию записи в файл?

Я понимаю, что можно написать свой контекстный менеджер, у которого в аргументах __exit__() будет информация об ошибке, но не уверен, что заменять уже готовый with open своим контекстным менеджером хорошая практика.

Что является хорошей практикой в такой ситуации?

Comments

[Олег Беж]

"Заворачивать" стоит запись(наверное, в зависимости от особенностей и задачи). А вот сам "with..." не стоит. Он сам знает, что ему делать.

with open...
try:
    f.write...
...

P.s.: Посмотрите "под капот" контекстному менеджеру, или почитайте о его специфике и "подкапотье" и многое само-собой переосмыслится.

[Михаил]

Я бы посоветовал написать декоратор)

[Сергей Горностаев]

Не стоит делать так:
except Exception as e:

[zlodiak]

Михаил, а писать декортатор для единственного места это хорошая практика?

[zlodiak]

Сергей Горностаев, но заметьте, я использую наиболее общее исключение Exception() в последнюю очередь. Разве это плохая практика?

[Сергей Горностаев]

zlodiak, плохая.

[zlodiak]

Сергей Горностаев, я думаю, это зависит от задачи. Например, если программа состоит из 1000 процедур и важно чтобы все они выполнились без ошибок, то да - лучше отлавливать конкретные виды исключений полностью контролировать процесс и иметь минимум неожиданностей.

А вот например когда есть программа, которая раз в сутки парсит 1 млн страниц и её устроит, если наберётся контента с этих страниц не менее 80%, то можно использовать наиболее общий блок Exception() как в моём примере. и в этом блоке будет содержаться какое-нибудь информационное действие типа записи в лог

[Сергей Горностаев]

zlodiak, две гипотетических ситуации:

1. Ваш парсер не имеет блока обработки "широких" исключений, падает на 79% собранных данных, теряя их. Вы анализируете бэктрейс и добавляете в код обработчик для того исключения, которое привело к падению. Вы потеряли день работы парсера, но теперь он годами стабильно работает, собирая каждый день около 80% информации.
   
2. Ваш парсер имеет блоки обработки "широких" исключений, на 79% собранных данных "бесшумно" переходит в неконсистентное состояние и следующие несколько месяцев обрабатывает только 1% от того, что мог бы обрабатывать, пока вы случайно не узнаете, что работа выполняется плохо. Вы потеряли месяцы.
   

Принципы "fail fast" и "let it crash" придуманы не так просто и есть веские причины, почему они набирают популярность в проектировании современных систем.