'Cuối cùng' có luôn thực thi trong Python không?

Đối với bất kỳ khối try-last nào có thể có trong Python, có đảm bảo rằng finallykhối sẽ luôn được thực thi không?

Ví dụ: giả sử tôi quay lại khi ở trong một exceptkhối:

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

Hoặc có thể tôi nâng cao lại Exception:

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

Thử nghiệm cho thấy điều finallyđó được thực thi cho các ví dụ trên, nhưng tôi tưởng tượng có những tình huống khác mà tôi chưa nghĩ đến.

Có bất kỳ tình huống nào trong đó một finallykhối có thể không thực thi trong Python không?

"Đảm bảo" là một từ mạnh mẽ hơn nhiều so với bất kỳ cách triển khai nào của finallyxứng đáng. Điều được đảm bảo là nếu việc thực thi chảy ra khỏi toàn bộ try- finallycấu trúc, thì nó sẽ chuyển qua công việc finallycần làm. Điều không được đảm bảo là việc thực thi sẽ chảy ra ngoài dấu try- finally.

• A finallytrong trình tạo hoặc chương trình không đồng bộ có thể không bao giờ chạy , nếu đối tượng không bao giờ thực thi để kết luận. Có rất nhiều cách có thể xảy ra; đây là một:

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

  Lưu ý rằng ví dụ này hơi phức tạp: khi trình tạo được thu thập rác, Python cố gắng chạy finallykhối bằng cách ném vào một GeneratorExitngoại lệ, nhưng ở đây chúng tôi bắt ngoại lệ đó và sau đó yieldlặp lại, tại thời điểm đó Python sẽ in một cảnh báo ("Trình tạo đã bỏ qua GeneratorExit ") và bỏ cuộc. Xem PEP 342 (Coroutines qua máy phát điện nâng cao) để biết thêm chi tiết.

  Các cách khác mà trình tạo hoặc chương trình điều tra có thể không thực thi để kết luận bao gồm nếu đối tượng không bao giờ được GC'ed (vâng, điều đó có thể xảy ra, ngay cả trong CPython), hoặc nếu một async with awaits trong __aexit__hoặc nếu đối tượng awaitlà hoặc yields trong một finallykhối. Danh sách này không nhằm mục đích đầy đủ.

• Một finallytrong một luồng daemon có thể không bao giờ thực thi nếu tất cả các luồng không phải daemon thoát ra trước.

• os._exitsẽ tạm dừng quá trình ngay lập tức mà không cần thực thi finallykhối.

• os.forkcó thể khiến finallykhối thực thi hai lần . Cũng như những sự cố bình thường mà bạn mong đợi từ những điều xảy ra hai lần, điều này có thể gây ra xung đột truy cập đồng thời (sự cố, ngừng hoạt động , ...) nếu quyền truy cập vào tài nguyên được chia sẻ không được đồng bộ hóa chính xác .

  Vì multiprocessingsử dụng fork-without-execute để tạo các quy trình của worker khi sử dụng phương thức fork start (mặc định trên Unix) và sau đó gọi os._exitworker sau khi công việc của worker hoàn thành, finallyvà multiprocessingtương tác có thể có vấn đề ( ví dụ ).

• Lỗi phân đoạn mức C sẽ ngăn finallycác khối chạy.
• kill -SIGKILLsẽ ngăn finallycác khối chạy. SIGTERMvà SIGHUPcũng sẽ ngăn finallycác khối chạy trừ khi bạn cài đặt một trình xử lý để tự điều khiển việc tắt máy; theo mặc định, Python không xử lý SIGTERMhoặc SIGHUP.
• Một ngoại lệ trong finallycó thể ngăn không cho hoàn tất quá trình dọn dẹp. Một trường hợp đặc biệt đáng chú ý là nếu người dùng nhấn control-C ngay khi chúng tôi bắt đầu thực thi finallykhối. Python sẽ nâng cao a KeyboardInterruptvà bỏ qua mọi dòng finallynội dung của khối. ( KeyboardInterruptMã an toàn rất khó viết).
• Nếu máy tính bị mất nguồn hoặc ở chế độ ngủ đông và không đánh thức, finallycác khối sẽ không chạy.

Các finallykhối không phải là một hệ thống giao dịch; nó không cung cấp sự đảm bảo về tính nguyên tử hoặc bất cứ thứ gì thuộc loại này. Một số ví dụ này có vẻ hiển nhiên, nhưng bạn rất dễ quên những điều như vậy có thể xảy ra và dựa vào finallyquá nhiều.

Đúng. Cuối cùng luôn luôn thắng.

Cách duy nhất để đánh bại nó là tạm dừng thực thi trước khi finally:có cơ hội thực thi (ví dụ: sập trình thông dịch, tắt máy tính của bạn, tạm dừng máy tạo vĩnh viễn).

Tôi tưởng tượng có những kịch bản khác mà tôi chưa nghĩ đến.

Dưới đây là một vài điều nữa mà bạn có thể chưa nghĩ đến:

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'

Tùy thuộc vào cách bạn thoát khỏi trình thông dịch, đôi khi bạn có thể "hủy" cuối cùng, nhưng không phải như thế này:

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

Sử dụng tính năng bấp bênh os._exit(theo ý kiến ​​của tôi thì điều này thuộc "sự cố trình thông dịch"):

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

Tôi hiện đang chạy mã này, để kiểm tra xem liệu cuối cùng có còn thực thi sau cái chết nhiệt của vũ trụ hay không:

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

Tuy nhiên, tôi vẫn đang chờ kết quả, vì vậy hãy kiểm tra lại tại đây sau.

Theo tài liệu Python :

Bất kể điều gì đã xảy ra trước đó, khối cuối cùng sẽ được thực thi khi khối mã hoàn tất và mọi ngoại lệ được nêu ra được xử lý. Ngay cả khi có lỗi trong trình xử lý ngoại lệ hoặc khối khác và một ngoại lệ mới được đưa ra, thì mã trong khối cuối cùng vẫn được chạy.

Cũng cần lưu ý rằng nếu có nhiều câu lệnh trả về, bao gồm một câu lệnh trong khối cuối cùng, thì câu lệnh trả về cuối cùng là câu lệnh duy nhất sẽ thực thi.

Vâng, có và không.

Điều được đảm bảo là Python sẽ luôn cố gắng thực thi khối cuối cùng. Trong trường hợp bạn quay trở lại từ khối hoặc đưa ra một ngoại lệ không cần thiết, khối cuối cùng sẽ được thực thi ngay trước khi thực sự trả lại hoặc nâng lên ngoại lệ.

(những gì bạn có thể tự mình kiểm soát bằng cách chạy mã trong câu hỏi của bạn)

Trường hợp duy nhất tôi có thể tưởng tượng nơi khối cuối cùng sẽ không được thực thi là khi bản thân trình thông dịch Python gặp sự cố, ví dụ như bên trong mã C hoặc vì mất điện.

Tôi tìm thấy cái này mà không sử dụng hàm máy phát:

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)

Ngủ có thể là bất kỳ mã nào có thể chạy trong khoảng thời gian không nhất quán.

Điều dường như đang xảy ra ở đây là quá trình song song đầu tiên kết thúc để lại thành công khối try, nhưng sau đó cố gắng trả về từ hàm một giá trị (foo) chưa được xác định ở bất kỳ đâu, điều này gây ra ngoại lệ. Ngoại lệ đó giết chết bản đồ mà không cho phép các quy trình khác tiếp cận các khối cuối cùng của chúng.

Ngoài ra, nếu bạn thêm dòng bar = bazzngay sau lệnh gọi sleep () trong khối thử. Sau đó, quá trình đầu tiên tiếp cận dòng đó sẽ ném ra một ngoại lệ (vì bazz không được xác định), điều này khiến khối cuối cùng của chính nó được chạy, nhưng sau đó giết bản đồ, khiến các khối thử khác biến mất mà không đến khối cuối cùng của chúng, và quá trình đầu tiên cũng không đạt được câu lệnh trả về của nó.

Điều này có nghĩa là đối với đa xử lý Python là bạn không thể tin tưởng cơ chế xử lý ngoại lệ để dọn dẹp tài nguyên trong tất cả các quy trình nếu ngay cả một trong các quy trình có thể có ngoại lệ. Việc xử lý tín hiệu bổ sung hoặc quản lý các tài nguyên bên ngoài lệnh gọi bản đồ đa xử lý sẽ là cần thiết.