Sorunun tarihi
Python 2.5'ten önce, try...finally ve try...except karşıt sözdizimsel bloklar olarak mevcutti, bu da geliştiricilerin hata yönetimi ve temizlik sağlamak için bunları beceriksizce iç içe yerleştirmesine neden oluyordu. PEP 341 bu yapıları birleştirdi ve finally'nin try bloğu nasıl çıkarsa çıksın çalışacağı modern garantiyi kurdu. Bu evrim, deterministic yok edicilerin olmadığı bir dilde güvenilir kaynak yönetimi kalıplarının uygulanması için çok önemliydi.
Sorun
Geliştiriciler genellikle açık bir return, break veya continue ifadesinin mevcut kapsamı hemen sona erdireceğini varsayıyorlar, bu da onu takip eden temizlik kodunu atlayabilir. finally bloklarının zorunlu olarak çalıştırılmaması durumunda, try bloğunda edinilen dosya yöneticileri, veritabanı bağlantıları veya kilitler gibi kaynaklar, erken bir dönüş tetiklendiğinde sızar. Bu durum, üretim sistemlerinde kaynak tükenmesine, kilitlenmelere veya veri bozulmasına yol açar.
Çözüm
Python'ın derleyicisi try...finally ifadesini belirli bayt kodu talimatlarına—SETUP_FINALLY, POP_BLOCK ve END_FINALLY—dönüştürerek, bir temizlik işleyicisini yorumlayıcının yürütme çerçevesine itmektedir. Bir return ile karşılaşıldığında, yorumlayıcı dönüş değerini değer yığına itiyor, finally bloğunun bayt kodunu çalıştırıyor ve yalnızca ardından bekleyen dönüşü işliyor. Eğer finally bloğu kendisi bir return yapar veya bir istisna fırlatırsa, bu yeni kontrol akışı eskiyi geçersiz kılarak temizlik işleminin öncelikli olmasını sağlar.
def process_file(path): f = open(path, 'r') try: data = f.read() if not data: return None # Sonuçta yine de çalışır! return data.upper() finally: f.close() print("Temizlik tamamlandı")
Sorun tanımı
Yüksek yük altında bir finansal işlem işleyen mikro hizmet, zaman zaman veritabanı bağlantı havuzunu tüketiyordu. İnceleme, sızıntıyı bir bağlantı edinip bir önbelleği kontrol eden, eğer önbellek başarılı olursa erkenden dönen bir yardımcı işlevde izledi. Geliştirici conn.close() çağrısını fonksiyonun sonunda yerleştirmişti, her zaman ulaşılacağını varsaydığından, ancak erken dönüşler bunu tamamen atlıyordu.
Çözüm 1: Manuel temizlik kopyalama
Ekip, conn.close() çağrısını her return ifadesinden önce kopyalamayı düşündü. Bu, gelecekteki modifikasyonların yeni çıkış noktaları ekleyebileceği için sürdürülemez olduğu gerekçesiyle reddedildi ve kopyalanmış kod DRY ilkesini ihlal ediyordu. Ayrıca bu yaklaşım, görsel dağınıklığı artırdı ve bakım sırasında insan hatası riskini yükseltti.
Çözüm 2: Bağlam yöneticileri
with get_connection() as conn: kullanarak yeniden yapılandırmayı değerlendirdiler. Her ne kadar ifade açısından normal olsa da, bu, dış bağlantı fabrikasının bağlam yöneticisi protokolünü derhal desteklemesini gerektiriyordu. Paylaşılan kütüphane kodunu değiştirme riski, acil dağıtım gerektiren bir sıcak düzeltme için faydaları aştı.
Çözüm 3: Try-finally sarmalayıcı
Seçilen yaklaşım, bağlantı mantığını try...finally bloğuna sararak uygulandı. Bu en az değişiklik, conn.close()'un herhangi bir dönüşten önce çalışmasını garanti etti ve bağımlılıkları yeniden yapılandırmadan sağladı. Acil durum güvenliği sağladı ve gelecekteki bakıcılar için temizlik garantisini belirgin bir şekilde iletti.
Sonuç
Düzeltme, dağıtımın üzerinden saatler geçmeden bağlantı sızıntısını ortadan kaldırdı. Bu model, kod tabanındaki tüm kaynak edinim işlevleri için linting kuralları aracılığıyla zorunlu hale getirildi. Bu da benzer gerilemeleri önledi ve hizmetin zirve yük altında istikrara kavuşmasını sağladı.
Bir finally bloğu, bir fonksiyonun dönüş değerini değiştirebilir veya bastırabilir mi?
Evet. Eğer finally bloğu kendi return ifadesini içeriyorsa, bu try veya except blokları tarafından üretilen herhangi bir değeri geçersiz kılar. Orijinal dönüş değeri tamamen atılır. Ayrıca, eğer finally bloğu bir istisna fırlatırsa, o istisna, önceki bloklardan gelen herhangi bir istisna veya dönüş değerinin yerini alır, dolayısıyla orijinal sonucu bastırır.
Eğer try bloğunda bir istisna fırlatılırsa ve finally bloğu da bir istisna fırlatırsa ne olur?
Orijinal istisna maskeleme yoluyla kaybolur. Python, finally bloğundaki istisnayı fırlatır ve ilk istisnanın yığıtı bırakılır, açıkça yakalanmadıkça. Bunu önlemek için, finally blokları, istisna fırlatma olasılığı olan işlemlerden kaçınmalı veya finally içinde bir iç try...except kullanarak temizlik hatalarını nazikçe ele almalı ve orijinal istisna bağlamını korumalıdır.
finally bloğunun çalışmaması garanti olan herhangi bir durum var mı?
Python'ın dil anlamsal kuralları finally yürütmesini normal kontrol akışı için garanti etse de, bazı felaket olayları bunu atlayabilir. Eğer işletim sistemi yakalanamaz bir sinyal gönderirse, SIGKILL gibi, os._exit() çağrılırsa veya Python süreci bir segmentasyon hatasıyla çökme durumuna girerse, yorumlayıcı, bekleyen finally bloklarını çalıştırmadan derhal sonlanır. Ayrıca, try bloğu içinde sonsuz bir döngü veya kilitlenme finally ifadesine ulaşılmasını tamamen engeller.