Jak kompilator **CPython** duplikuje zestaw `finally` w różnych offsetach bajtkodu, aby obsłużyć normalne zakończenie, wyjątki i jawne zwroty, a jaką rolę odgrywa stos bloków w zachowaniu stanu pośredniego w trakcie tego przetwarzania?

Odpowiedź na pytanie.

Historia pytania: Przed Pythonem 2.5 interakcja między instrukcjami return w blokach finally a aktywnymi wyjątkami była niejednoznaczna i zależna od platformy. PEP 341 ustandaryzował hierarchię wyjątków i ustalił zasadę, że blok finally wykonuje się przed zakończeniem funkcji, ale szczegóły implementacyjne, jak interpreter zachowuje oczekujące wartości zwrotne lub wyjątki podczas wykonywania kodu sprzątającego, pozostały szczegółem kompilatora. Mechanizm ten zapewnia, że zasoby są zwalniane w sposób przewidywalny, nie tracąc z oczu, czy funkcja powinna zwrócić wartość, propagować wyjątek, czy przekazać kontrolę.

Problem: Kiedy CPython kompiluje instrukcję try-finally, musi uwzględnić trzy różne ścieżki zakończenia: normalne zakończenie, jawne return z wartością na stosie oraz propagowany aktywny wyjątek. Wyzwanie polega na zapewnieniu, że zestaw finally zostanie wykonany we wszystkich przypadkach, jednocześnie pozwalając mu na ewentualne nadpisanie statusu zakończenia (np. return w finally tłumi wyjątek z try), bez uszkodzenia stosu wartości lub utraty informacji o oczekującym wyjątku. Wymaga to od kompilatora emituowania bajtkodu bloku finally w wielu miejscach i korzystania ze stosu bloków ramki do tymczasowego przechowywania kontekstu wykonania.

Rozwiązanie: Kompilator emituje zestaw finally raz na końcu bloku try, a następnie duplikuje go (lub skacze do niego) w określonych offsetach dla obsługi wyjątków i ścieżek zwrotu. Opcode SETUP_FINALLY umieszcza blok na stosie bloków ramki, który wskazuje na wersję kodu finally obsługującą wyjątki. Kiedy występuje wyjątek, interpreter korzysta z tego wpisu na stosie, aby skoczyć do obsługi. W przypadku normalnych zwrotów POP_BLOCK usuwa obsługę, ale jeśli pojawia się return wewnątrz try, interpreter zapisuje wartość zwrotna, wykonuje zestaw finally, a jeśli ten zestaw kończy się bez nowego return, przywraca oryginalną wartość zwrotną. Jeśli blok finally zawiera własny return, po prostu wykonuje RETURN_VALUE, co nadpisuje oczekującą wartość zwrotną lub tłumi aktywny wyjątek, usuwając stan wyjątku i zwracając nową wartość.

import dis

def example():
    try:
        return "try_value"
    finally:
        return "finally_value"

# Bajtkod pokazuje, że logika finally jest duplikowana
# w offsetach dla obsługi wyjątków i normalnych zwrotów
dis.dis(example)

Sytuacja z życia

Opis problemu: W systemie przetwarzania transakcji finansowych funkcja process_withdrawal() uzyskuje blokadę wątku, aby zapewnić atomowe aktualizacje salda. Blok try oblicza nową równowagę i przygotowuje rekord transakcji do zwrócenia. Jednak kontrola zgodności w bloku finally wykrywa podejrzany sygnał na koncie. Wymaganiem jest zawsze zwolnienie blokady (sprzątanie), ale jeśli sygnał jest ustawiony, należy zwrócić zamiast rekordu transakcji zawiadomienie o odrzuceniu, skutecznie tłumiąc udane obliczenie.

Różne rozważane rozwiązania:

Jednym z podejść było całkowite unikanie return wewnątrz bloku finally. Zamiast tego, przechowywano obliczony wynik w zmiennej lokalnej result, wykonywano kontrolę zgodności w finally, modyfikowano result do zawiadomienia o odrzuceniu w razie potrzeby i umieszczano pojedyncze return result po bloku finally. Zaletami tej metody są jawny przepływ kontrolny, który jest łatwy do zrozumienia i debugowania przez młodszych programistów, a także unikanie subtelnego zachowania dotyczącego tłumienia zwrotów. Wady obejmują zwiększoną werbalność kodu i ryzyko zapomnienia o zwróceniu zmiennej po bloku finally, co spowodowałoby, że funkcja zwróci None domyślnie.

Innym rozważanym rozwiązaniem było użycie menedżera kontekstu do uzyskania blokady i obsługi logiki zgodności za pomocą wyjątków. Jeśli wykryto sygnał, rzucano niestandardowy ComplianceError z bloku finally (lub z funkcji zagnieżdżonej), przechwytywano go na zewnątrz i zwracano zawiadomienie o odrzuceniu z obsługi wyjątku. Zalety obejmują przestrzeganie zasady, że finally powinien być tylko do sprzątania, a nie do logiki biznesowej, oraz wykorzystywanie mechanizmu wyjątków Pythona do sterowania przepływem. Wady obejmują narzut związany z tworzeniem wyjątków oraz fakt, że rzucenie nowego wyjątku, gdy inny może być aktywny (jeśli blok try nie powiódł się), zatajałby oryginalny błąd, komplikując debugowanie.

Które rozwiązanie zostało wybrane (i dlaczego): Zespół wybrał pierwsze rozwiązanie (zmienna lokalna z post-finalnym zwrotem) pomimo werbalności. Uzasadnieniem było to, że użycie return wewnątrz finally, aby tłumić wartości, chociaż technicznie poprawne, tworzyło "pułapkę", w której przyszli konserwatorzy mogliby dodać logowanie lub metryki do bloku finally, nie zdając sobie sprawy, że mogliby przez przypadek tłumić wyjątki lub wartości zwrotne, jeśli dodaliby instrukcję return. Podejście z użyciem jawnej zmiennej uczyniło przepływ danych przejrzystym i regularnie przechodziło testy statyczne.

Rezultat: Implementacja skutecznie zapobiegała zakleszczeniom, zapewniając, że blokada była zawsze zwalniana przez blok finally, podczas gdy logika zgodności poprawnie zwracała zawiadomienia o odrzuceniu bez ujawniania obliczonych danych transakcji. Wyraźna struktura uprościła także testowanie jednostkowe, umożliwiając wstrzykiwanie mocków w określonych punktach bez obaw o niejawne ścieżki zwrotów, a przeglądy kodu stały się szybsze, ponieważ przepływ kontrolny był liniowy.

Czego często brakuje kandydatom

Dlaczego instrukcja break lub continue wewnątrz bloku finally także tłumi aktywny wyjątek, i jak to różni się od return pod względem czyszczenia stosu?

Kiedy blok finally wykonuje się w wyniku aktywnego wyjątku, interpreter przechowuje typ wyjątku, wartość i ślad stosu w stanie ramki. Jeśli blok finally wykonuje break lub continue, CPython jawnie czyści stan wyjątku (używając POP_BLOCK i resetując zmienne wyjątkowe) przed przejściem do celu przepływu kontrolnego pętli. Efektywnie to powoduje utratę wyjątku. Różnica względem return jest subtelna: return umieszcza wartość na stosie i sygnalizuje ramce, że należy zakończyć, podczas gdy break/continue skacze do offsetu bajtkodu. Obie operacje powodują rozwinięcie stosu bloków, co obejmuje czyszczenie stanu wyjątku, ale return również obsługuje zachowanie stosu wartości dla wartości zwrotnej, podczas gdy break po prostu usuwa wszelkie oczekujące informacje o wyjątkach bez zachowania wartości dla wywołującego.

Jak obecność wyrażenia yield wewnątrz bloku try-finally zmienia generację bajtkodu dla sprzątania, szczególnie w odniesieniu do zawieszania generatora?

Kiedy CPython wykrywa yield wewnątrz bloku try z powiązanym finally, generuje opkod YIELD_VALUE, a następnie specjalne przetwarzanie w END_FINALLY. Problem polega na tym, że generator może zostać wstrzymany w punkcie yield, a jeśli generator zostanie później zamknięty (poprzez close() lub zbieranie śmieci), interpreter musi wznowić generator, aby wykonać blok finally. Jest to obsługiwane przez logikę GENERATOR_RETURN (lub RETURN_GENERATOR w nowszych wersjach) i YIELD_FROM. Kompilator dodaje SETUP_FINALLY jak zwykle, ale wskaźnik f_lasti ramki (ostatnia instrukcja) umożliwia re-wejście. Jeśli generator zostanie zamknięty, Python wzbudza wyjątek GeneratorExit w punkcie zawieszenia, co powoduje wykonanie bloku finally przed zakończeniem generatora. Kandydaci często nie zauważają, że yield zmusza kod finally do ochrony przed ponownym wejściem oraz że obiekt generatora przechowuje odniesienie do ramki, utrzymując blok finally wykonalnym po zawieszeniu.

Co się dzieje z kontekstem wyjątku (__context__ i __cause__), gdy blok finally rzuca nowy wyjątek podczas obsługi istniejącego?

Jeśli blok finally rzuca nowy wyjątek, podczas gdy stary jest aktywny (czy to z bloku try, czy propagowany), nowy wyjątek staje się "bieżącym" wyjątkiem, a stary wyjątek jest dołączany do jego atrybutu __context__ w ramach łańcucha kontekstów. Jeśli blok finally używa raise NewException() from None, jawnie łamie łańcuch, ustawiając __suppress_context__ na True. Jednak jeśli blok finally wykonuje return zamiast rzucania, wyjątek jest całkowicie tłumiony (zgodnie z główną odpowiedzią), a żadne łańcuchowanie się nie odbywa, ponieważ stan wyjątku jest czyszczony z ramki przed zakończeniem funkcji. Kandydaci często mylą to z zachowaniem wewnątrz bloków except, gdzie raise bez from automatycznie tworzy łańcuch, nie zdając sobie sprawy, że bloki finally uczestniczą w tym łańcuchu w sposób identyczny do każdego innego bloku kodu, ale z dodatkowymi zawirowaniami, że mogą być wykonywane podczas rozwijania stosu.