Найти - Пользователи
Полная версия: простой вопрос про "finally:"
Начало » Python для новичков » простой вопрос про "finally:"
1
erjemin
Если внутри функции надо по какому-то условию вывалиться по return() к этому времени открыт коннекторы в файлы и базы, организованы курсоры и пр. надо ли все это в явном виде закрывать (в смысле коннекторы и курсоры)??? Или можно все закрывающее затолкать в finally: и не ломать мозг что и где уже закрыто/открыто???
Lexander
erjemin
коннекторы в файлы и базы, организованы курсоры и пр.
Вот это все где открывается?

Если внутри функции, то они все еще будут жить до момента, когда garbage collector не решит, что их пора закрывать.
Если вам нужно обеспечить быстрое освобождение ресурсов, закрывайте их явно.
erjemin
Все открывается в функции… В ней же исключения обрабатываются… Но т.к. условий много то или городить лестницу if и в каждой явно обрабатывать весь кусок кода (получится аналог swith case, читабельнее, но более громоздко и куски повторяющегося кода), или разбирать if последоавательно, что сильно оптимизирует код, но придется все отслеживать или наедятся на finally: внутри функции

Кстати, если я что-то повторно закрою не страшно? Что происходит если закрытые коннекты повторно пытаются закрыть???
Lexander
erjemin
Кстати, если я что-то повторно закрою не страшно? Что происходит если закрытые коннекты повторно пытаются закрыть???
Вообще то зависит от библиотек.

Даже если у вас return внутри блока try-except, ваш finally все равно выполнится.
А вот если return внутри finally, то вернется именно это значение - из finally.

И еще посмотрите сможете ли вы использовать конструкцию with - она сама закроет файлы (и другие объекты, которые работают с with) даже в случае исключений.
erjemin
Спасибо! НО что-то я подумал и решил вообще все переписать…

И еще, я бывший Си-шник и потому важно: все эти открывания коннектов в базы, формирование курсоров, открытий файлов затратно по ресурсам? А то может запихнуть все по функциям. Например фукнция записи в лог. Кидаешь в нее значение, а она открывает файл-записывает-закрывает. Сейчас я открываю заранее (т.к. думаю это ресурсноемко) и уже в функции (или пере ее вызовом) отслеживаю исключения. Я конечно понимаю что любые исключения жрут ресурс больше чем любой открытый курсор-коннек, но в моем случае исключение один раз… Т.е. я открываю все что мне нужно и уж если все ок, то уже все функции объявляю…
erjemin
О еще вопрос:

Даже если у вас return внутри блока try-except, ваш finally все равно выполнится.
А вот если return внутри finally, то вернется именно это значение - из finally.

А если у меня в finally тоже return но какой-то другой (в смысле возвращает что-то свое) то как? По мне идеально если finally будет работать как что-то пост-return … типа все закрой и выведи статусы…
Lexander
erjemin
все эти открывания коннектов в базы, формирование курсоров, открытий файлов затратно по ресурсам?
Да, конечно. Эти затраты не зависят от языка.
Соединение с базой делайте одно на все приложение.
Можно использовать пул соединений, если это нужно. Но тоже 1 пул на все приложение.
Так не только эффективнее, но и правильно, в соответствии с рекомендациями PEP.
PEP - это набор спецификаций и стандартов для Питона.

Вы упомянули о самописном логгировании, встроенная библиотека logging не подошла или просто о ней не знаете?

erjemin
А если у меня в finally тоже return но какой-то другой (в смысле возвращает что-то свое) то как?
Сработает именно он и только он, даже при наличии return в блоке try.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Powered by DjangoBB