Czy „w końcu” zawsze jest wykonywane w Pythonie?

Czy dla każdego możliwego bloku try-Final w Pythonie jest zagwarantowane, że finallyblok będzie zawsze wykonywany?

Na przykład, powiedzmy, że wracam będąc w exceptbloku:

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

A może przebijam ponownie Exception:

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

Testy pokazują, że finallytak się dzieje w powyższych przykładach, ale wyobrażam sobie, że istnieją inne scenariusze, o których nie pomyślałem.

Czy istnieją scenariusze, w których finallyblok może nie zostać wykonany w Pythonie?

„Gwarantowane” to o wiele mocniejsze słowo, niż jakakolwiek realizacja na to finallyzasługuje. Gwarantowane jest to, że jeśli wykonanie wypłynie z całości try- finallyconstruct, przejdzie przez to, finallyaby to zrobić. Nie można zagwarantować, że wykonanie wypłynie z try- finally.

• A finallyw generatorze lub programie asynchronicznym może nigdy nie działać , jeśli obiekt nigdy nie zostanie zakończony. Może się to zdarzyć na wiele sposobów; Tu jest jeden:

  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.')
  

  Zauważ, że ten przykład jest trochę skomplikowany: kiedy generator jest zbierany jako śmieci, Python próbuje uruchomić finallyblok, rzucając GeneratorExitwyjątek, ale tutaj łapiemy ten wyjątek i yieldznowu, w którym to momencie Python wyświetla ostrzeżenie ("generator zignorowany GeneratorExit ”) i poddaje się. Aby uzyskać szczegółowe informacje, patrz PEP 342 (Coroutines via Enhanced Generators) .

  Inne sposoby, w jakie generator lub procedura mogą nie wykonać, aby wyciągnąć wnioski, obejmują to, czy obiekt nigdy nie został poddany GC (tak, jest to możliwe, nawet w CPythonie), lub jeśli async with awaitjest w __aexit__lub jeśli obiekt awaitjest lub yieldjest w finallybloku. Ta lista nie jest wyczerpująca.

• A finallyw wątku demona może nigdy nie zostać wykonany, jeśli wszystkie wątki inne niż demonowe zakończą się jako pierwsze.

• os._exitnatychmiast zatrzyma proces bez wykonywania finallybloków.

• os.forkmoże spowodować dwukrotne wykonaniefinally bloków . Oprócz zwykłych problemów, których można się spodziewać po zdarzeniach podwójnych, może to powodować współbieżne konflikty dostępu (awarie, blokady, ...), jeśli dostęp do współdzielonych zasobów nie jest poprawnie zsynchronizowany .

  Ponieważ multiprocessingużywa fork-without-exec do tworzenia procesów roboczych podczas korzystania z metody fork start (domyślna w systemie Unix), a następnie wywołuje os._exitproces roboczy po zakończeniu pracy pracownika, finallya multiprocessinginterakcja może być problematyczna ( przykład ).

• Błąd segmentacji na poziomie C uniemożliwi finallyuruchomienie bloków.
• kill -SIGKILLzapobiegnie finallyuruchamianiu bloków. SIGTERMa SIGHUPtakże uniemożliwi finallyuruchamianie bloków, chyba że zainstalujesz program obsługi, który sam kontroluje zamknięcie; domyślnie Python nie obsługuje SIGTERMani SIGHUP.
• Wyjątek w programie finallymoże uniemożliwić ukończenie czyszczenia. Szczególnie godny uwagi jest przypadek, gdy użytkownik kliknie Ctrl-C tylko jako zaczynamy wykonać finallyblok. Python podniesie a KeyboardInterrupti pominie każdy wiersz finallyzawartości bloku. ( KeyboardInterrupt-bezpieczny kod jest bardzo trudny do napisania).
• Jeśli komputer traci moc lub przechodzi w stan hibernacji i nie budzi się, finallybloki nie będą działać.

finallyBlok nie jest system transakcyjny; nie zapewnia gwarancji atomowości ani niczego w tym rodzaju. Niektóre z tych przykładów mogą wydawać się oczywiste, ale łatwo jest zapomnieć, że takie rzeczy mogą się zdarzyć i polegać na finallyzbyt dużym stopniu.

Tak. Wreszcie zawsze wygrywa.

Jedynym sposobem na pokonanie tego jest zatrzymanie wykonywania, zanim finally:będzie można je wykonać (np. Zawieszenie interpretera, wyłączenie komputera, zawieszenie generatora na zawsze).

Wyobrażam sobie, że są inne scenariusze, o których nie pomyślałem.

Oto kilka innych, o których być może nie pomyślałeś:

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'

W zależności od tego, jak zrezygnowałeś z tłumaczenia, czasami możesz ostatecznie „anulować”, ale nie w ten sposób:

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

Używanie precarious os._exit(moim zdaniem zalicza się to do „crash the interpreter”):

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

Obecnie uruchamiam ten kod, aby sprawdzić, czy w końcu nadal będzie działać po śmierci wszechświata na gorąco:

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

Jednak wciąż czekam na wynik, więc wróć tutaj później.

Zgodnie z dokumentacją Pythona :

Bez względu na to, co stało się wcześniej, ostatni blok jest wykonywany po zakończeniu bloku kodu i obsłużeniu wszelkich podniesionych wyjątków. Nawet jeśli wystąpi błąd w programie obsługi wyjątków lub bloku else i zostanie zgłoszony nowy wyjątek, kod w ostatnim bloku jest nadal wykonywany.

Należy również zauważyć, że jeśli istnieje wiele instrukcji powrotu, w tym jedna w bloku final, to jedyny, który zostanie wykonany, będzie zwracany ostatni blok.

Cóż, tak i nie.

Gwarantowane jest to, że Python zawsze będzie próbował wykonać ostatni blok. W przypadku powrotu z bloku lub zgłoszenia nieprzechwyconego wyjątku, ostatni blok jest wykonywany tuż przed faktycznym zwróceniem lub podniesieniem wyjątku.

(co mogłeś kontrolować, uruchamiając kod w swoim pytaniu)

Jedyny przypadek, jaki mogę sobie wyobrazić, w którym ostatni blok nie zostanie wykonany, to sytuacja, w której sam interpreter Pythona ulega awarii, na przykład w kodzie C lub z powodu przerwy w zasilaniu.

Znalazłem ten bez użycia funkcji generatora:

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)

Uśpienie może być dowolnym kodem, który może działać przez niespójne okresy czasu.

Wydaje się, że dzieje się tutaj to, że pierwszy równoległy proces kończący pomyślnie opuszcza blok try, a następnie próbuje zwrócić z funkcji wartość (foo), która nie została nigdzie zdefiniowana, co powoduje wyjątek. Ten wyjątek zabija mapę, nie pozwalając innym procesom dotrzeć do ich ostatecznych bloków.

Ponadto, jeśli dodasz linię bar = bazztuż po wywołaniu funkcji sleep () w bloku try. Następnie pierwszy proces osiągający tę linię zgłasza wyjątek (ponieważ bazz nie jest zdefiniowany), który powoduje uruchomienie własnego bloku końcowego, ale następnie zabija mapę, powodując, że inne bloki próbne znikają bez dotarcia do ich ostatecznych bloków, i również pierwszy proces, aby nie dotrzeć do instrukcji return.

W przypadku wieloprocesorowości Pythona oznacza to, że nie można ufać mechanizmowi obsługi wyjątków w zakresie czyszczenia zasobów we wszystkich procesach, jeśli nawet jeden z procesów może mieć wyjątek. Konieczna byłaby dodatkowa obsługa sygnału lub zarządzanie zasobami poza wywołaniem mapy wieloprocesowej.

Dodatek do zaakceptowanej odpowiedzi, aby pomóc zobaczyć, jak to działa, z kilkoma przykładami:

• To:

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

  wyjdzie

  Wreszcie

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

  wyjdzie

  z wyjątkiem w
  końcu