Чи "нарешті" завжди виконується в Python?

Чи гарантується будь-який можливий блок спробу в остаточному підсумку в Python, що finallyблок завжди буде виконуватися?

Наприклад, скажімо, я повертаюсь у exceptблоці:

try:
    1/0
except ZeroDivisionError:
    return
finally:
    print("Does this code run?")

А може, я знову піднімаю Exception:

try:
    1/0
except ZeroDivisionError:
    raise
finally:
    print("What about this code?")

Тестування показує, що finallyвиконується для вищезазначених прикладів, але я думаю, що є й інші сценарії, про які я не думав.

Чи є сценарії, в яких finallyблок не може виконатись у Python?

"Гарантоване" - це набагато сильніше слово, ніж будь-яка реалізація finallyзаслуговує. Гарантоване, що якщо виконання витікає з цілого try- finallyконструювати, воно пройде через те, finallyщоб це зробити. Що не гарантується, що виконання буде витікати з try- finally.

• A finallyв генераторі або асинхронній програмі ніколи не може працювати , якщо об'єкт ніколи не виконує висновок. Є багато способів, які могли б статися; ось один:

  def gen(text):
      try:
          for line in text:
              try:
                  yield int(line)
              except:
                  # Ignore blank lines - but catch too much!
                  pass
      finally:
          print('Doing important cleanup')
  
  text = ['1', '', '2', '', '3']
  
  if any(n > 1 for n in gen(text)):
      print('Found a number')
  
  print('Oops, no cleanup.')

  Зауважте, що цей приклад трохи хитромудрий: коли генератор збирає сміття, Python намагається запустити finallyблок, кидаючи GeneratorExitвиняток, але тут ми вловлюємо це виняток і потім yieldзнову, після чого Python друкує попередження ("генератор проігнорував GeneratorExit ") і здається. Докладні відомості див. У розділі PEP 342 (Коротифікації через покращені генератори) .

  Інші способи, які генератор або супровід може не виконати для висновку, включають, якщо об'єкт просто ніколи не є GC'ed (так, це можливо навіть у CPython), або якщо async with awaits в __aexit__, або якщо об'єкт awaits або yields в finallyблоці. Цей список не є вичерпним.

• A finallyв демоновій нитці ніколи не може виконуватися, якщо всі недемонові потоки вийдуть першими.

• os._exitзупинить процес негайно без виконання finallyблоків.

• os.forkможе викликати finallyблоки виконати двічі . Окрім звичайних проблем, яких ви очікуєте від подій, що трапляються двічі, це може спричинити одночасні конфлікти доступу (збої, стійла, ...), якщо доступ до спільних ресурсів не синхронізований правильно .

  Оскільки multiprocessingвикористовується fork-without-exec для створення робочих процесів при використанні методу запуску fork (за замовчуванням у Unix), а потім викликає os._exitпрацівника, коли робота робітника виконана, finallyі multiprocessingвзаємодія може бути проблематичною ( приклад ).

• Помилка сегментації на рівні C запобіжить finallyзапуску блоків.
• kill -SIGKILLзапобіжить finallyзапуску блоків. SIGTERMа SIGHUPтакож запобіжить finallyзапуску блоків, якщо ви не встановите обробник для управління відключенням самостійно; за замовчуванням Python не обробляє SIGTERMабо SIGHUP.
• Виняток у finallyможе запобігти завершенню очищення. Особливо примітний випадок, якщо користувач натискає на Control-C так само, як ми починаємо виконувати finallyблок. Python підніме a KeyboardInterruptі пропустить кожен рядок вмісту finallyблоку. ( KeyboardInterrupt-забезпечити код дуже важко).
• Якщо комп'ютер втрачає живлення або перебуває в сплячку і не прокидається, finallyблоки не запускаються.

finallyБлок не є система транзакцій; він не дає гарантій атомності або нічого подібного. Деякі з цих прикладів можуть здатися очевидними, але легко забути такі речі можуть трапитися і покладатися на них finallyзанадто багато.

Так. Нарешті завжди виграє.

Єдиний спосіб перемогти це - зупинити виконання, перш ніж finally:отримати шанс виконання (наприклад, збій перекладача, вимкнення комп'ютера, призупинення генератора назавжди).

Я думаю, є й інші сценарії, про які я не думав.

Ось ще пара, про яку ви, можливо, не думали:

def foo():
    # finally always wins
    try:
        return 1
    finally:
        return 2

def bar():
    # even if he has to eat an unhandled exception, finally wins
    try:
        raise Exception('boom')
    finally:
        return 'no boom'

Залежно від способу виходу з перекладача, іноді ви можете "скасувати" нарешті, але не так:

>>> import sys
>>> try:
...     sys.exit()
... finally:
...     print('finally wins!')
... 
finally wins!
$

Використовуючи нестабільний os._exit(на мою думку, це під «крах перекладача»):

>>> import os
>>> try:
...     os._exit(1)
... finally:
...     print('finally!')
... 
$

Я зараз запускаю цей код, щоб перевірити, чи остаточно він виконається після теплової смерті Всесвіту:

try:
    while True:
       sleep(1)
finally:
    print('done')

Однак я все ще чекаю результату, тому перевірте тут пізніше.

Відповідно до документації Python :

Незалежно від того, що відбувалося раніше, остаточний блок виконується після завершення блоку коду та оброблення будь-яких підвищених винятків. Навіть якщо є помилка в обробці винятків або в блоці else і порушено новий виняток, код у фінальному блоці все ще виконується.

Слід також зазначити, що якщо є кілька операторів повернення, включаючи одне в остаточному блоці, то повернення остаточно блоку є єдиним, яке буде виконуватися.

Ну так і ні.

Гарантоване, що Python завжди намагатиметься виконати остаточний блок. У випадку, коли ви повертаєтеся з блоку або піднімаєте невиконаний виняток, нарешті блок виконується безпосередньо перед поверненням або підвищенням винятку.

(що ви могли контролювати, просто запустивши код у своєму запитанні)

Єдиний випадок, який я можу собі уявити, коли остаточний блок не буде виконаний - це коли сам інтерпретатор Python виходить з ладу, наприклад, всередині коду С або через відключення електроенергії.

Я знайшов цю без використання функції генератора:

import multiprocessing
import time

def fun(arg):
  try:
    print("tried " + str(arg))
    time.sleep(arg)
  finally:
    print("finally cleaned up " + str(arg))
  return foo

list = [1, 2, 3]
multiprocessing.Pool().map(fun, list)

Сном може бути будь-яким кодом, який може працювати за непослідовну кількість часу.

Тут, мабуть, відбувається те, що перший паралельний процес, який завершується, успішно залишає блок спробу, але потім намагається повернути з функції значення (foo), яке ніде не було визначено, що спричиняє виняток. Цей виняток вбиває карту, не дозволяючи іншим процесам досягти їх остаточних блоків.

Крім того, якщо ви додасте рядок bar = bazzвідразу після сну (), дзвоніть у спробу блоку. Тоді перший процес для досягнення цього рядка викидає виняток (оскільки баз не визначений), який призводить до запуску власного блоку, але потім вбиває карту, внаслідок чого інші блоки спробу зникають, не дійшовши до їх остаточних блоків, і перший процес також не досяг свого повернення.

Що означає для багатопроцесорної обробки Python, це те, що ви не можете довіряти механізму обробки винятків для очищення ресурсів у всіх процесах, якщо навіть один із процесів може мати виняток. Буде необхідним додаткове оброблення сигналу або управління ресурсами поза багатовикористовувальним викликом карти.

Додайте до прийнятої відповіді, щоб допомогти побачити, як вона працює, з кількома прикладами:

• Це:

   try:
       1
   except:
       print 'except'
   finally:
       print 'finally'

  виведе

  нарешті

•    try:
         1/0
     except:
         print 'except'
     finally:
         print 'finally'

  виведе

  крім
  нарешті