Come duplica il compilatore di **CPython** il blocco `finally` tra diversi offset di bytecode per gestire il completamento normale, le eccezioni e i ritorni espliciti, e quale ruolo gioca lo stack dei blocchi nel preservare lo stato intermedio durante questa gestione?

Risposta alla domanda.

Storia della domanda: Prima di Python 2.5, l'interazione tra le dichiarazioni return nei blocchi finally e le eccezioni attive era ambigua e dipendeva dalla piattaforma. PEP 341 ha standardizzato la gerarchia delle eccezioni e ha consolidato la regola secondo cui i blocchi finally vengono eseguiti prima dell'uscita dalla funzione, ma i dettagli di implementazione su come l'interprete preserva i valori di ritorno in attesa o le eccezioni durante l'esecuzione del codice di pulizia sono rimasti un dettaglio interno del compilatore. Questo meccanismo assicura che le risorse vengano rilasciate in modo prevedibile senza perdere traccia di se la funzione dovrebbe restituire un valore, propagare un'eccezione o cedere il controllo.

Il problema: Quando CPython compila un'istruzione try-finally, deve tenere conto di tre percorsi di uscita distinti: caduta normale, un return esplicito con un valore nello stack, e un'eccezione attiva che viene propagata. La sfida consiste nell'assicurare che il blocco finally venga eseguito in tutti i casi mentre consente di sovrascrivere potenzialmente lo stato di uscita (ad esempio, un return in finally sopprime un’eccezione da try), senza danneggiare lo stack dei valori o perdere le informazioni sulle eccezioni in attesa. Questo richiede che il compilatore emetta il bytecode del blocco finally in più posizioni e utilizzi lo stack dei blocchi del frame per riporre temporaneamente il contesto di esecuzione.

La soluzione: Il compilatore emette il blocco finally una volta alla fine del blocco try, quindi lo duplica (o vi salta) a specifici offset per la gestione delle eccezioni e i percorsi di ritorno. L'opcode SETUP_FINALLY spinge un blocco nello stack dei blocchi del frame che punta alla versione del codice finally del gestore delle eccezioni. Quando si verifica un'eccezione, l'interprete utilizza questa voce dello stack per saltare al gestore. Per i ritorni normali, POP_BLOCK rimuove il gestore, ma se si verifica un return all'interno di try, l'interprete salva il valore di ritorno, esegue il blocco finally, e se quel blocco si completa senza un nuovo return, ripristina il valore di ritorno originale. Se il blocco finally contiene un proprio return, esegue semplicemente RETURN_VALUE, che sovrascrive il valore di ritorno in attesa o sopprime l'eccezione attiva ripristinando lo stato dell'eccezione e restituendo il nuovo valore.

import dis

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

# Il bytecode mostra che la logica del finally è duplicata
# a offset per la gestione delle eccezioni e il ritorno normale
dis.dis(example)

Situazione dalla vita reale

Descrizione del problema: In un sistema di elaborazione di transazioni finanziarie, una funzione process_withdrawal() acquisisce un lock di thread per garantire aggiornamenti di bilancio atomici. Il blocco try calcola il nuovo saldo e prepara un record di transazione da restituire. Tuttavia, un controllo di conformità nel blocco finally rileva un flag sospetto sull'account. Il requisito è sempre rilasciare il lock (la pulizia), ma se il flag è impostato, restituire un avviso di rifiuto invece del record di transazione, sopprimendo di fatto il calcolo riuscito.

Diverse soluzioni considerate:

Un approccio era evitare completamente return all'interno del blocco finally. Invece, memorizzare il risultato calcolato in una variabile locale result, eseguire il controllo di conformità in finally, modificare result nell'avviso di rifiuto se necessario, e posizionare un'unica dichiarazione return result dopo il blocco finally. I pro di questo metodo includono un flusso di controllo esplicito che è facile da seguire e debug per gli sviluppatori junior, e evita il comportamento sottile della soppressione del ritorno. I contro includono una maggiore verbosità del codice e il rischio di dimenticare di restituire la variabile dopo il blocco finally, il che causerebbe il ritorno implicito di None dalla funzione.

Un'altra soluzione considerata era usare un gestore di contesto per l'acquisizione del lock e gestire la logica di conformità tramite eccezioni. Se veniva rilevato il flag, sollevare un'eccezione personalizzata ComplianceError dal blocco finally (o da una funzione annidata), gestirla all'esterno, e restituire l'avviso di rifiuto dal gestore delle eccezioni. I pro includono l'aderenza al principio che finally dovrebbe essere solo per la pulizia, non per la logica di business, e sfruttare il meccanismo delle eccezioni di Python per il flusso di controllo. I contro includono il sovraccarico della creazione di eccezioni e il fatto che sollevare una nuova eccezione mentre potrebbe esserne attiva un'altra (se il blocco try ha fallito) maschererebbe l'errore originale, complicando il debug.

Quale soluzione è stata scelta (e perché): Il team ha scelto la prima soluzione (variabile locale con ritorno dopo il finally) nonostante la verbosità. La razionale era che utilizzare return all'interno di finally per sopprimere valori, pur essendo tecnicamente valido, creava un "footgun" dove i futuri manutentori potrebbero aggiungere logging o metriche al blocco finally senza rendersi conto che potrebbero accidentalmente sopprimere eccezioni o valori di ritorno se avessero aggiunto una dichiarazione return. L'approccio esplicito con variabile ha reso il flusso dei dati trasparente e ha superato i controlli di analisi statica in modo più affidabile.

Risultato: L'implementazione ha prevenuto con successo i deadlock garantendo che il lock venisse sempre rilasciato tramite il blocco finally, mentre la logica di conformità ha restituito correttamente avvisi di rifiuto senza perdere i dati delle transazioni calcolate. La struttura esplicita ha anche semplificato i test unitari consentendo l'iniezione di mock a punti specifici senza preoccuparsi dei percorsi di ritorno impliciti, e le revisioni del codice sono diventate più rapide poiché il flusso di controllo era lineare.

Cosa spesso perdono i candidati

Perché un'istruzione break o continue all'interno di un blocco finally sopprime anche un'eccezione attiva, e come si differenzia da un return in termini di pulizia dello stack?

Quando un blocco finally viene eseguito a causa di un'eccezione attiva, l'interprete memorizza il tipo di eccezione, il valore e il traceback nello stato del frame. Se il blocco finally esegue un break o continue, CPython cancella esplicitamente lo stato dell'eccezione (utilizzando POP_BLOCK e ripristinando le variabili di eccezione) prima di saltare al bersaglio del flusso di controllo del ciclo. Questo perde effettivamente l'eccezione. La differenza rispetto a return è sottile: return pone un valore nello stack e segnala al frame di uscire, mentre break/continue saltano a un offset di bytecode. Entrambe le operazioni innescano il disimballaggio dello stack dei blocchi, che include la cancellazione dello stato dell'eccezione, ma return gestisce anche la preservazione dello stack dei valori per il valore di ritorno, mentre break semplicemente scarta eventuali informazioni di eccezione in attesa senza preservare un valore per il chiamante.

Come altera la presenza di un'espressione yield all'interno di un blocco try-finally la generazione di bytecode per la pulizia, in particolare riguardo alla sospensione del generatore?

Quando CPython rileva un yield all'interno di un blocco try con un associato finally, genera opcodes YIELD_VALUE seguiti da una gestione speciale in END_FINALLY. Il problema è che un generatore può essere sospeso al punto di yield, e se successivamente il generatore viene chiuso (tramite close() o raccolta dei rifiuti), l'interprete deve riprendere il generatore per eseguire il blocco finally. Questo è gestito dalla logica GENERATOR_RETURN (o RETURN_GENERATOR nelle versioni più recenti) e YIELD_FROM. Il compilatore aggiunge SETUP_FINALLY come al solito, ma il puntatore f_lasti del frame (ultima istruzione) consente la reinserzione. Se il generatore è chiuso, Python solleva un'eccezione GeneratorExit al punto di sospensione, attivando l'esecuzione del blocco finally prima che il generatore termini veramente. I candidati spesso perdono che yield costringe il codice finally ad essere protetto contro la reinserzione, e che l'oggetto generatore mantiene un riferimento al frame, mantenendo il blocco finally eseguibile dopo la sospensione.

Cosa succede al contesto delle eccezioni (__context__ e __cause__) quando un blocco finally solleva una nuova eccezione mentre gestisce una precedente?

Se un blocco finally solleva una nuova eccezione mentre una vecchia è attiva (sia dal blocco try che in fase di propagazione), la nuova eccezione diventa l'eccezione "corrente", e la vecchia eccezione è collegata al suo attributo __context__ tramite la catena di contesto. Se il blocco finally utilizza raise NewException() from None, interrompe esplicitamente la catena impostando __suppress_context__ su True. Tuttavia, se il blocco finally esegue un return anziché sollevare, l'eccezione viene completamente soppressa (secondo la risposta principale), e nessuna catena si verifica perché lo stato dell'eccezione viene cancellato dal frame prima che la funzione esca. I candidati spesso confondono questo con il comportamento all'interno dei blocchi except, dove raise senza from crea automaticamente la catena, non rendendosi conto che i blocchi finally partecipano a questo meccanismo di catena in modo identico a qualsiasi altro blocco di codice, ma con la complessità aggiuntiva che potrebbero essere in esecuzione durante il disimballaggio dello stack.