Soru tarihçesi:
Python 2.5'ten önce, finally bloklarındaki return ifadeleri ile aktif istisnalar arasındaki etkileşim belirsiz ve platforma bağımlıydı. PEP 341, istisna hiyerarşisini standartlaştırdı ve finally bloklarının işlev çıkışından önce yürütülmesi kuralını sağlamlaştırdı, ancak yorumlayıcının temizleme kodunu yürütürken bekleyen dönüş değerlerini veya istisnaları nasıl koruduğu içsel bir derleyici detayı olarak kaldı. Bu mekanizma, kaynakların öngörülebilir bir şekilde serbest bırakılmasını sağlarken, işlevin bir değer döndürmesi, bir istisna yayması veya kontrolü vermesi gerektiğini kaybetmeyi önler.
Problem:
CPython bir try-finally ifadesini derlediğinde, üç farklı çıkış yolunu dikkate almak zorundadır: normal akış, yığın üzerinde bir değere sahip açık bir return ve propagasyona tabi olan aktif bir istisna. Zorluk, finally bloğunun tüm durumlarda çalışmasını sağlarken, çıkış durumunu potansiyel olarak geçersiz kılmasına (örneğin, finally içinde bir return istisnayı bastırır) izin vermek, yığın değerini bozmadan veya bekleyen istisna bilgisini kaybetmeden bunu gerçekleştirmektir. Bu, derleyicinin finally bloğunun bytecode'unu birden fazla konumda yayımlamasını ve çerçevenin blok yığınına yürütme bağlamını geçici olarak depolamak için başvurmasını gerektirir.
Çözüm:
Derleyici, try bloğunun sonunda bir kez finally bloğunu yayımlar, ardından istisna işleme ve dönüş yolları için spesifik offsetlerde bunu çoğaltır (veya bunun üzerine atlar). SETUP_FINALLY opcode'u, finally kodunun istisna işleyici versiyonunu işaret eden çerçevenin blok yığına bir blok iterek kullanır. Bir istisna meydana geldiğinde, yorumlayıcı bu yığın girişi kullanarak işleyiciye atlar. Normal dönüşlerde, POP_BLOCK işleyiciyi kaldırır, ancak bir return try içinde meydana gelirse, yorumlayıcı dönüş değerini kaydeder, finally bloğunu yürütür ve eğer bu blok yeni bir return olmadan tamamlanmışsa, orijinal dönüş değerini geri yükler. Eğer finally bloğu kendi return ifadesini içeriyorsa, yalnızca RETURN_VALUE yürütülür, bu da bekleyen dönüş değerinin üzerini kaplar veya aktif istisnayı bastırarak istisna durumunu temizler ve yeni değeri döndürür.
import dis def example(): try: return "try_value" finally: return "finally_value" # Bytecode, finally mantığının çoğaltıldığını gösterir # istisna işleme ve normal dönüş için offsetlerde dis.dis(example)
Problem tanımı:
Bir finansal işlem işleme sisteminde, process_withdrawal() işlevi atomik bakiye güncellemelerini sağlamak için bir başlık kilidi alır. try bloğu yeni bakiyeyi hesaplar ve döndürülmek üzere bir işlem kaydı hazırlar. Ancak, finally bloğundaki bir uyum kontrolü hesapta şüpheli bir bayrağı tespit eder. Gerekçe her zaman kilidi serbest bırakmaktır (temizlik), ancak bayrak ayarlanmışsa, işlem kaydının üzerine bir reddetme bildirimi döndürmek, başarılı hesaplamayı etkili bir şekilde bastırmak gerekmektedir.
Değerlendirilen farklı çözümler:
Bir yaklaşım, finally bloğunun içine return ifadesi koymaktan tamamen kaçınmaktı. Bunun yerine, hesaplanan sonucu bir yerel result değişkeninde saklamak, finally bloğunda uyum kontrolü gerçekleştirmek, gerekirse result'ı reddetme bildirimi olarak değiştirmek ve finally bloğundan sonra tek bir return result ifadesi koymak. Bu yöntemin avantajları, kontrol akışının açık olması, genç geliştiricilerin takip etmesi ve hata ayıklaması kolay olması ve dönüş bastırma konusunda ince davranışları önlemesidir. Dezavantajları arasında artan kod sadeliği ve finally bloğundan sonra değişkeni döndürmeyi unutma riski bulunmaktadır ki bu durum işlevin None döndürmesine neden olur.
Diğer bir değerlendirilen çözüm ise, kilit alımını yönetmek için bir bağlam yöneticisi kullanmak ve uyum mantığını istisnalar aracılığıyla ele almaktı. Eğer bayrak tespit edilirse, finally bloğundan (veya bir iç işlevden) özel bir ComplianceError oluşturmak, dışarıda yakalamak ve istisna işleyicisinden reddetme bildirimini döndürmek. Avantajları, finally'nin yalnızca temizlik için olması gerektiği ilkesine uymak, iş mantığı içermemek ve Python'un istisna mekanizmasını kontrol akışında kullanarak oluşturmasıdır. Dezavantajları arasında istisna oluşturma maliyetinin olması ve yeni bir istisna oluşturmanın, eğer try bloğu başarısız olduysa, başka bir aktif bir istisna varken orijinal hatayı maskelese, hata ayıklamayı karmaşıklaştırması bulunmaktadır.
Hangi çözüm seçildi (ve neden):
Ekip, her ne kadar ayrıntılı olsa da, ilk çözümü (yerel değişken ile post-final return) tercih etti. Rasyonel, finally içinde değerleri bastırmak için return kullanmanın, teknik olarak geçerli olsa da, gelecekteki bakım yapanlar için bir "tehlike" yaratmasıydı; bu insanlar, finally bloğuna loglama veya metrik eklerken bu durumun aksine harekete geçebileceklerini anlamadan return ifadesi ekleyebilirlerdi. Açık değişken yaklaşımı veri akışını şeffaf hale getirdi ve statik analiz kontrollerinden daha güvenilir geçti.
Sonuç:
Uygulama, kilidin her zaman finally bloğu aracılığıyla serbest bırakılmasını sağlayarak çıkmazları önledi ve uyum mantığı, hesaba geçirilen işlem verilerini sızdırmadan reddetme bildirimlerini doğru bir şekilde döndürdü. Açık yapı, belirli noktalarda mock enjeksiyonu ile yapı birim testlerini basit hale getirirken, gizli dönüş yollarına ilişkin endişe duymadan kod incelemeleri daha hızlı hale geldi çünkü kontrol akışı doğrusaldı.
Neden finally bloğunda bir break veya continue ifadesinin de aktif bir istisnayı bastırdığını ve bunun yığın temizliği açısından return dan nasıl farklı olduğunu açıklar mısınız?
Bir finally bloğu, aktif bir istisna nedeniyle yürütüldüğünde, yorumlayıcı istisna türünü, değerini ve traceback'i çerçevenin durumuna kaydeder. Eğer finally bloğu bir break veya continue yürütürse, CPython açıkça istisna durumunu temizler (yani POP_BLOCK kullanarak ve istisna değişkenlerini sıfırlayarak) ve döngü kontrol akış hedefine atlar. Bu etkin bir şekilde istisnayı kaybettirir. return ile olan fark ince bir noktadır: return, yığın üzerinde bir değer yerleştirir ve çerçevenin çıkmasını işaret ederken, break veya continue bir bytecode offset'ine atlayarak çalışır. Her iki işlem de blok yığınının sarmasını tetikler, bu da istisna durumunu temizlemeyi içerir, ancak return ayrıca dönüş değeri için yığın korunmasını da yönetir, oysa break yalnızca mevcut istisna bilgisinin kaybolmasına neden olur.
Bir try-finally bloğu içinde yield ifadesinin varlığı, özellikle jeneratör askıya alma ile ilgili temizlik için bytecode oluşturulmasını nasıl değiştirir?
CPython, bir try bloğunda ve buna bağlı bir finally de yield ifadesini tespit ettiğinde, YIELD_VALUE opcode'larını ve ardından END_FINALLY içinde özel işleme iletir. Problemi, bir jeneratör yield noktasında askıya alınabilir ve eğer jeneratör daha sonra close() veya çöp toplama yoluyla kapatılırsa, yorumlayıcının jeneratörü yeniden başlatması ve finally bloğunu yürütmesi gerekir. Bu, GENERATOR_RETURN (veya yeni sürümlerde RETURN_GENERATOR) ve YIELD_FROM mantığı ile ele alınır. Derleyici SETUP_FINALLY'yi her zamanki gibi ekler, ancak çerçevenin f_lasti (son talimat) göstericisi yeniden girişe izin verir. Eğer jeneratör kapatılırsa, Python, askıya alma noktasında bir GeneratorExit istisnası yükseltir ve bu, jeneratör gerçekten sonlanmadan önce finally bloğunu yürütür. Adaylar, yield ifadesinin, finally kodunun yeniden girişe karşı korunmalı olmasını sağladığını ve jeneratör nesnesinin bir çerçeve referansı tuttuğunu gözden kaçırıyorlar; bu da finally bloğunu askıya alındıktan sonra yürütülür hale getiriyor.
Bir finally bloğu, mevcut bir hata ile başa çıkarken yeni bir istisna yükseldiğinde istisna bağlamı (__context__ ve __cause__) ne olur?
Eğer bir finally bloğu, eski bir hata aktifken (ya try bloğundan veya propagasyondan) yeni bir istisna yükseltirse, yeni istisna "mevcut" istisna haline gelir ve eski istisna onun __context__ niteliğine bağlanır. Eğer finally bloğu raise NewException() from None kullanırsa, bu açıkça zinciri keser ve __suppress_context__'ı True olarak ayarlar. Ancak, finally bloğu raise yerine return gerçekleştirirse, istisna tamamen bastırılır (ana yanıta göre) ve bir zincirleme olmaz çünkü istisna durumu, işlev çıktığında çerçeveden temizlenir. Adaylar, istisna blokları içindeki bu davranışı, from olmadan raise etmenin otomatik zincir oluşturduğunu karıştırma eğilimindedir; fakat finally bloklarının bu zincirleme mekanizmasına, diğer kod blokları gibi katıldığını kabul etseler de, yürütme sırasında yığın sarılması yaşandığı için ek karmaşıklıkların olabileceğini fark etmemektedirler.