Swift ha introdotto un gestore di errori strutturato nella versione 2.0, sostituendo i modelli di puntatori agli errori di Objective-C con una semantica nativa di throw e catch. La parola chiave rethrows è emersa per risolvere la specifica frizione in cui funzioni generiche di ordine superiore come map o filter costringevano i chiamanti a utilizzare try anche quando passavano chiusure non lancianti, creando una cerimonia di gestione degli errori non necessaria.
Il problema riguarda il polimorfismo degli effetti delle funzioni e il subtyping. Nel sistema dei tipi di Swift, una chiusura non lanciata è un sottotipo di una chiusura lanciata perché soddisfa il contratto "potrebbe lanciare" non lanciando mai. Senza rethrows, una funzione che accetta una chiusura lanciata deve propagare incondizionatamente le eccezioni, costringendo tutti i punti di chiamata a gestire errori indipendentemente dal comportamento effettivo dell'argomento.
La soluzione è l'annotazione rethrows, che stabilisce un contratto condizionale: la funzione lancia solo se il suo parametro di chiusura lancia. Il compilatore di Swift implementa questo tracciando la capacità di lancio degli argomenti di chiusura al momento della compilazione. Quando viene passata una chiusura non lanciata, la funzione è trattata come non lanciata nel punto di chiamata, eliminando la necessità di try; quando viene passata una chiusura lanciata, la funzione eredita l'effetto di lancio.
Stavamo costruendo una pipeline modulare di trasformazione dei dati per un'applicazione iOS in cui gli utenti potevano concatenare operazioni come parsing di JSON, ridimensionamento delle immagini e hashing crittografico. La funzione centrale pipeline accettava un array di trasformazioni definite come (Data) throws -> Data. Inizialmente, abbiamo utilizzato un'annotazione standard throws su pipeline, che costringeva ogni punto di chiamata a racchiudere anche semplici trasformazioni in blocchi do-catch, nonostante molte operazioni fossero funzioni pure senza modalità di errore.
Il nostro primo approccio duplicava l'intera funzione: una versione chiamata pipeline per trasformazioni non lancianti e un'altra chiamata pipelineThrowing per quelle lancianti. Questa separazione consentiva punti di chiamata puliti ma creava un incubo di manutenzione dove ogni correzione di bug richiedeva la modifica di due posizioni, e la superficie API raddoppiava con ogni nuova opzione di configurazione. Inoltre, gli utenti dovevano conoscere i dettagli di implementazione per scegliere il metodo corretto, violando i principi di incapsulamento.
Il secondo approccio manteneva una singola firma throws ma incoraggiava l'uso di try? per silenziare gli avvertimenti, di fatto scartando le informazioni sugli errori e rendendo impossibile il debug quando si verificavano errori reali. Questo violava le garanzie di sicurezza e rendeva il codice fragile, poiché gli sviluppatori dimenticavano di gestire casi di errore genuini in pipeline miste contenenti sia operazioni sicure che non sicure.
Alla fine, abbiamo adottato la soluzione rethrows, dichiarando func pipeline(_ transforms: [(Data) throws -> Data]) rethrows -> Data. Questo ha permesso al compilatore di applicare try solo quando l'array di chiusure conteneva operazioni lancianti, consentendo chiamate dirette per computazioni pure. Il risultato è stata una riduzione del 40% del codice boilerplate, l'eliminazione delle firme di funzione duplicate e un miglioramento nell'ergonomia dell'API in cui il sistema dei tipi rifletteva accuratamente i veri domini degli errori di casi d'uso specifici.
Perché Swift vieta di lanciare errori direttamente all'interno del corpo di una funzione rethrows piuttosto che esclusivamente attraverso il parametro closure?
La parola chiave rethrows crea un contratto di trasparenza rigorosa che afferma che la funzione propaga solo errori generati dai suoi argomenti. Se tenti di throw CustomError() direttamente nel corpo della funzione, il compilatore di Swift lo rifiuta perché rappresenta un lancio incondizionato, violando la garanzia "solo se la chiusura lancia". La funzione deve gestire i propri errori internamente utilizzando do-catch, convertirli in valori di ritorno o elevare la firma a throws incondizionato, garantendo che i chiamanti possano presupporre in sicurezza che non origini nuovi domini di errore dalla funzione stessa.
Come interagisce rethrows con più parametri di chiusura e quali sono le implicazioni per la propagazione degli effetti?
Quando una funzione ha più parametri di chiusura contrassegnati come lancianti e la funzione stessa è contrassegnata come rethrows, la funzione lancia se uno qualsiasi delle chiusure lancia, creando un'unione di effetti. Il compilatore di Swift traccia questi effetti individualmente lungo la catena di chiamate, quindi comporre funzioni rethrows preserva la natura condizionale senza intervento manuale. Tuttavia, se trasformi o incapsuli le chiusure prima di passarle, devi preservare la firma di lancio nell'incapsulatore, altrimenti il compilatore tratterà l'argomento come non lanciato, facendo sì che la funzione esterna perda la sua capacità di lancio condizionale.
Qual è la relazione tra rethrows e @autoclosure, e perché questo schema appare nelle API di asserzione?
La combinazione di @autoclosure e rethrows consente una valutazione pigra con propagazione degli errori condizionale, dove l'autoclosure ritarda la valutazione fino al momento necessario e la funzione lancia solo se quella valutazione ritardata lancia. Questo schema alimenta le funzioni di Swift assert e precondition, consentendo di passare espressioni lancianti alle asserzioni senza dover contrassegnare la chiamata di asserzione con try. I candidati spesso trascurano che l'autoclosure deve dichiarare esplicitamente () throws -> T per partecipare al contratto rethrows, e che questo meccanismo separa il tempo di valutazione (pigro) dalla semantica di propagazione degli errori (condizionale), che è cruciale per i percorsi di codice critici per le prestazioni in cui le asserzioni sono disabilitate nelle build di rilascio.