Sviluppo Software

Il principio Fail Fast e le Guard Clauses: basta codice a forma di freccia

Scritto da Marco Morello il 19 Aprile 2026

💡 TL;DR: Controllare gli errori alla fine di lunghi blocchi if annidati (Arrow Code) distrugge la leggibilità. Il principio Fail Fast impone di verificare i dati in ingresso e uscire subito (Guard Clauses). Per la logica di business complessa, abbandona le eccezioni e abbraccia il Result Pattern.

Immagina questa scena: ti arriva il corriere in officina con i dischi freno nuovi per la tua XT1200Z. Cosa fai? Smonti le pinze, togli la ruota, tiri giù i vecchi dischi, apri la scatola nuova e... ti accorgi che ti hanno mandato quelli di un T-MAX.

Bestemmia, rimonti tutto, perdi mezza giornata.

Un meccanico esperto fa una cosa diversa: prende la scatola ancora prima di toccare la moto, la apre sul banco, prende il calibro e verifica i fori. Se non vanno bene, scarta il pezzo alla porta. Questo, nello sviluppo software, si chiama Fail Fast. Fallisci in fretta.

Se non applichi questo principio, finisci per scrivere il famigerato "Arrow Code" (codice a forma di freccia). E fidati, è uno dei motivi principali per cui i bug si nascondono, la manutenzione diventa un incubo e ai colloqui tecnici vieni scartato.

1. L'incubo dell'Arrow Code e il carico cognitivo

Guarda questo blocco di codice C#. È la classica roba che trovi nei sistemi legacy scritti di fretta da chi pensa "basta che funzioni":

public void ProcessaTagliandoMoto(Moto moto, Meccanico meccanico)
{
    if (moto != null)
    {
        if (meccanico != null)
        {
            if (meccanico.IsDisponibile)
            {
                if (moto.KmAttuali >= 10000)
                {
                    // 5 livelli di indentazione! 
                    // Qui dentro inizia la vera logica di business.
                    EseguiCambioOlio(moto);
                    AggiornaLibretto(moto);
                }
                else
                {
                    Log.Info("Tagliando non ancora necessario.");
                }
            }
            else
            {
                throw new InvalidOperationException("Il meccanico è in pausa caffè.");
            }
        }
        else
        {
            throw new ArgumentNullException(nameof(meccanico));
        }
    }
    else
    {
        throw new ArgumentNullException(nameof(moto));
    }
}

Vedi la forma a > che ha preso il codice? L'indentazione si sposta sempre più a destra. Perché questo è il male assoluto? Non è solo una questione estetica, è un problema di biologia del cervello umano.

La nostra memoria a breve termine (la RAM del nostro cervello) può tenere traccia di circa 4 o 5 concetti contemporaneamente. Quando leggi un codice annidato in quel modo, il tuo cervello deve ricordarsi: "Ok, sono qui dentro perché la moto esiste, e il meccanico esiste, e il meccanico è libero, e i km sono più di 10.000... aspetta, e questo else a riga 22 a quale if apparteneva?"

È come leggere un libro in cui ogni frase ha (una parentesi (che contiene un'altra parentesi (e un'altra ancora)) prima di darti) il verbo. Vai in Stack Overflow mentale.

2. La soluzione: Guard Clauses e Return Early

Per risolvere questo disastro, i programmatori Senior ribaltano la logica. Invece di dire "se tutto va bene, allora fai questo", dicono "se qualcosa va male, esci subito. Altrimenti procedi".

Questo approccio usa le Guard Clauses (clausole di guardia). Pensa a loro come ai buttafuori di una discoteca. I buttafuori stanno alla porta. Non entrano nel locale per rincorrerti e chiederti i documenti mentre stai già ballando. Ti controllano all'ingresso. Non hai la carta d'identità? Non sei in lista? Hai le scarpe sbagliate? Fuori subito (Return Early).

Se passi la "dogana" dei buttafuori, significa che sei in regola. Una volta dentro il locale (il cuore della funzione), non ci sono più controlli. Quello è il famoso Happy Path (il percorso felice).

public void ProcessaTagliandoMoto(Moto moto, Meccanico meccanico)
{
    // --- GUARD CLAUSES (i buttafuori alla porta) ---
    if (moto == null) throw new ArgumentNullException(nameof(moto));
    if (meccanico == null) throw new ArgumentNullException(nameof(meccanico));
    if (!meccanico.IsDisponibile) throw new InvalidOperationException("Non disponibile.");

    if (moto.KmAttuali < 10000)
    {
        Log.Info("Tagliando non ancora necessario.");
        return; // Return Early: esci subito, senza errori, ma esci.
    }

    // --- HAPPY PATH (sei dentro al locale, la pista da ballo) ---
    // Niente indentazione. Logica chiara e diretta.
    EseguiCambioOlio(moto);
    AggiornaLibretto(moto);
}

Boom. Leggibilità aumentata del 300%. Chi legge questo codice non deve "tenere a mente" nulla. Legge la riga 3: "Se manca la moto, scoppia". Perfetto. Lo capisce e passa oltre. Il cervello è libero. Gli errori (i throw) sono di fianco alla condizione che li genera, non sepolti cento righe più sotto in un else disperso nel nulla.

public void PianificaViaggio(Moto moto, Pilota pilota)
{
    if (moto != null)
    {
        if (pilota != null)
        {
            if (moto.Carburante > 0)
            {
                if (pilota.HaLaPatente)
                {
                    // Codice a freccia!
                    AvviaMotore();
                }
                else { throw new Exception("No patente"); }
            }
            else { throw new Exception("Vuoto"); }
        }
        else { throw new ArgumentNullException(); }
    }
}

public void PianificaViaggio(Moto moto, Pilota pilota)
{
    // --- GUARD CLAUSES ---
    if (moto == null) throw new ArgumentNullException();
    if (pilota == null) throw new ArgumentNullException();
    if (moto.Carburante <= 0) throw new Exception();
    if (!pilota.HaLaPatente) throw new Exception();

    // --- HAPPY PATH ---
    AvviaMotore();
}

3. Eccezioni vs Result Pattern: il livello architetturale

Fin qui abbiamo parlato di sintassi per rendere il codice leggibile. Ma se vuoi passare le selezioni per diventare Senior o Architetto, devi capire cosa succede "sotto il cofano".

Nel codice sopra abbiamo usato throw new Exception(). Lanciare un'eccezione non è gratuito. Nello sviluppo software, lanciare un'eccezione è come tirare il freno a mano d'emergenza di un treno in corsa.

Quando tiri il freno a mano, il treno non si ferma e basta. C'è un caos enorme: stridore di freni, scintille, gente che cade, il macchinista che deve chiamare la centrale (nel codice questo si chiama stack trace unwinding: il sistema operativo deve risalire tutto l'albero delle chiamate in memoria per capire chi deve gestire l'errore). Costa un sacco di risorse al tuo server.

Tireresti il freno a mano d'emergenza solo perché un passeggero non ha il biglietto? Assolutamente no. Manderesti il controllore a fargli la multa. Il freno a mano lo tiri se mancano i binari.

Allo stesso modo, un database che cade o un disco fisso che si brucia sono vere eccezioni (mancano i binari). Invece, un utente che inserisce una password sbagliata, un meccanico che è occupato o una moto che non ha abbastanza km per il tagliando non sono eventi eccezionali. Sono banali regole del gioco (Domain Logic). Sono passeggeri senza biglietto.

Il Result Pattern: il controllore dei biglietti

Per gestire i fallimenti delle regole di business senza usare il devastante throw come controllo di flusso, i professionisti usano il Result Pattern.

Invece di far esplodere un errore, la tua funzione restituisce sempre un oggetto. Immagina questo oggetto come un pacco di Amazon con allegata una bolla di accompagnamento. Chi riceve il pacco legge la bolla: c'è scritto "Consegna Avvenuta" (Successo) oppure "Destinatario Assente, riprovare" (Fallimento e motivazione). Il tutto in modo civile, senza far deragliare treni.

// Creiamo il nostro "pacco con la bolla" usando i record di C# 9+
// Un record è perfetto perché è immutabile, non si può modificare in viaggio.
public record Result(bool IsSuccess, string ErrorMessage = null)
{
    // Metodi comodi per creare velocemente l'esito
    public static Result Success() => new(true);
    public static Result Failure(string message) => new(false, message);
}

// Il nostro metodo rivisto, ora super performante e civile:
public Result ProcessaTagliandoMoto(Moto moto, Meccanico meccanico)
{
    // I buttafuori ora non urlano e non sparano. Danno solo una motivazione.
    if (moto == null) return Result.Failure("Attenzione: hai passato una moto vuota.");
    if (meccanico == null) return Result.Failure("Attenzione: meccanico non identificato.");
    if (!meccanico.IsDisponibile) return Result.Failure("Il meccanico in questo momento è occupato.");

    // Pista da ballo (Happy Path)
    EseguiCambioOlio(moto);
    
    return Result.Success(); // Tutto è andato a buon fine!
}

Perché tutto questo sforzo? Guardiamo come si comporta chi chiama questo metodo (ad esempio la tua interfaccia utente su .NET MAUI o il tuo controller API):

// Nessun try/catch pesante!
var risultato = ProcessaTagliandoMoto(miaYamaha, marioMeccanico);

if (!risultato.IsSuccess)
{
    // Mostro gentilmente all'utente cosa non va, usando il messaggio dalla bolla
    MostraPopupUtente(risultato.ErrorMessage);
    return;
}

// Aggiorno la UI con una spunta verde.
MostraSuccesso();

Questo è codice da architetto. È prevedibile, non consuma risorse inutili e, soprattutto, è estremamente facile da testare (scrivere unit test per verificare se una funzione restituisce un Result.Success è molto più rapido e solido che fare test che si aspettano un'eccezione e devono intercettarla).