La Gestione Eccezioni non è Magia Nera, è il Lavoro Sporco che Salva il Tuo Software (e il Tuo Stipendio)

Quel lunedì mattina in cui tutto è andato a fuoco. Di nuovo.

Mettiamola così: c’è il software che funziona sulla tua macchina e c'è il software che viene preso a pugni dalla realtà. Quello che gira in produzione. Quello che, il lunedì mattina, decide di andare a gambe all’aria senza un perché apparente, mandando nel panico il team, facendo urlare i clienti e trasformando te, CTO o capo-progetto, nell'uomo che deve metterci una pezza. E in fretta. Non è un bug. È un'emorragia di soldi, tempo e, peggio, di credibilità. Questo è il mondo reale, quello dove una gestione delle eccezioni fatta male non è un dettaglio tecnico, ma un costo operativo nascosto che divora i margini. Un urlo silenzioso che ti dice solo una cosa: la tua architettura software non è pronta per la trincea.

Noi di ThinkPink Studio, con un piede nella pignoleria toscana e l'altro nell'arte di arrangiarsi connettendosi da Kampala, di progetti promettenti trasformati in incubi abbiamo i cassetti pieni. Non si tratta di un pezzo di codice che "si rompe". Si tratta di un cliente che perde dati. Di una falla di sicurezza che si apre come una voragine. Di un e-commerce che smette di incassare. È il costo del *non fare*, astronomicamente più alto di qualsiasi fatica preventiva. Nel 2026, pensare che "tanto non succede" non è più un'opzione. È una condanna.

La Prima Regola del Caos: Se non sai cos'è, non puoi domarlo

Prima di combattere il mostro, bisogna dargli un nome. Nell'arena di Java, un'eccezione è solo il programma che alza la mano e dice: "Capo, qui sta succedendo qualcosa di strano, che faccio?". Non è un Error, quello è il sistema che ti molla del tutto (tipo OutOfMemoryError) e c'è poco da fare se non bestemmiare e riavviare. Un'Exception, invece, è un problema che *puoi* e *devi* prevedere.

La gerarchia è semplice. Ci sono le Checked Exception, quelle che il compilatore ti sbatte in faccia (IOException, SQLException). Ti costringe a gestirle, con un throws o con un try-catch. È il tuo collega pignolo che ti dice: "Sei sicuro di quello che stai facendo? Guarda che qui si può spaccare tutto".

E poi ci sono loro, le Unchecked Exception (o RuntimeException). Le più bastarde. NullPointerException, ArrayIndexOutOfBoundsException. Non devi gestirle per forza, il codice compila lo stesso. E così, il dev frettoloso o il junior con troppa fiducia nel prossimo le ignora. Risultato? Il botto in produzione, al momento sbagliato, per la ragione più stupida.

Le Regole non Scritte (che nel 2026 tutti fingono di seguire)

Il modo in cui un team gestisce le eccezioni la dice lunga sulla sua anzianità di servizio. Non basta un try-catch messo a casaccio. Ci vuole una strategia. Ecco cosa abbiamo imparato prendendo schiaffi sui server, da Rosignano a Kampala.

1. Pesca il pesce giusto, non prosciugare il lago

L'orrore numero uno: catch (Exception e). È l'equivalente di mettere un cerotto su una ferita d'arma da fuoco. Mascheri il sintomo, non curi la malattia. Anzi, rendi la diagnosi impossibile. Stai dicendo al sistema: "Qualsiasi cosa succeda, fai finta di niente". Catturare eccezioni specifiche (IOException, IllegalArgumentException) è l'unica via per sapere *esattamente* cosa è andato storto e perché.

2. Mai, e dico MAI, ingoiare un'eccezione

Il blocco catch vuoto. Se lo vediamo in una code review, parte un cicchetto. È la resa incondizionata. Significa silenziare un errore, nascondere la polvere sotto il tappeto e sperare che nessuno se ne accorga. Fino a quando, ovviamente, il sistema crolla e nessuno sa perché. Un'eccezione va *almeno* loggata. Sempre. O rilanciata, se non è compito tuo gestirla in quel punto.

3. Loggare non è scrivere un diario: il contesto è tutto

Loggare "Errore!" è inutile. È come andare dal meccanico e dire "la macchina fa un rumore". Bravo, e quindi? Un log decente, nel 2026, deve contenere lo stack trace, certo, ma soprattutto il contesto: a quale utente è successo? Con quali parametri di richiesta? In un'architettura a microservizi, senza un ID di correlazione che lega le chiamate tra i vari servizi, un log è solo rumore bianco. L'osservabilità non è un lusso, è l'unica cosa che ti permette di fare debug senza impazzire.

4. Lascia che Java pulisca per te: usa il try-with-resources

File, connessioni, stream. Tutta roba che va aperta e *chiusa*. Dimenticarsi un close() in un blocco finally è un classico che porta a memory leak lenti e inesorabili. Dal 2007 Java 7 ha introdotto il try-with-resources. Usalo. Garantisce che ogni risorsa AutoCloseable venga chiusa, qualunque cosa accada. Meno codice, meno errori, meno problemi.

5. Se il dizionario non ha la parola, inventala: le Eccezioni Custom

A volte, le eccezioni standard non bastano a descrivere un problema di *business*. Un InvalidCustomerStatusException dice molto di più di un generico IllegalStateException. Creare eccezioni custom, specifiche per il tuo dominio, rende il codice auto-documentante e la logica di gestione degli errori molto più pulita. L'importante è non mangiarsi l'eccezione originale quando ne crei una nuova.

6. La balla colossale del costo delle eccezioni

Tutti l'abbiamo sentita: "le eccezioni sono lente". Certo, creare uno stack trace e risalire la catena di chiamate ha un costo. Ma stiamo parlando di situazioni *eccezionali*. Se il tuo codice lancia eccezioni l'1% delle volte, il loro impatto sulle performance è un granello di sabbia nel deserto. Il costo *reale* non è lanciare un'eccezione. Il costo reale è un downtime di tre ore, un team di cinque persone che fa debugging alla cieca, la perdita di dati di un cliente e la tua reputazione che va a picco. Quello sì, che è costoso.

Osservabilità: Guardare la propria creatura dall'alto

Nei sistemi a microservizi, un errore è una reazione a catena. Un servizio lento ne rallenta altri tre, che a loro volta ne fanno fallire un quarto. Senza una visione d'insieme, sei un rabdomante bendato. L'osservabilità – l'unione di metriche, log e tracing distribuito – è il tuo satellite spia. Strumenti come OpenTelemetry, Jaeger o stack come ELK non sono più roba da Golia della Silicon Valley. Sono la normalità per chiunque voglia capire cosa diavolo sta succedendo nel proprio sistema distribuito.

La nostra filosofia: dalla Maremma all'Uganda, la resilienza è universale

Una PMI di Rosignano può pensare che questa roba sia troppo complessa. La verità è che i mattoni sono gli stessi per tutti. Costruire un software robusto significa che il tuo gestionalino, sviluppato con la cura di un artigiano toscano, non tirerà le cuoia sotto Natale. Significa che il sistema di logistica, che i nostri ragazzi a Kampala hanno ottimizzato per funzionare anche quando la rete singhiozza, saprà gestire un timeout senza far sparire un ordine. Questo non è un vezzo da ingegneri, è la base della continuità operativa.

A Kampala abbiamo imparato sulla nostra pelle che la resilienza non è un'opzione. È una lezione che applichiamo ovunque. Le aziende che investono qui, oggi, non solo passano meno tempo a spegnere incendi, ma sono più veloci a costruire domani. Perché il loro codice non è un campo minato.

Il tuo codice è un asset o un debito tecnico in attesa di esplodere?

La gestione delle eccezioni non è un capitolo di un manuale di programmazione. È la linea che separa un software professionale da un accrocchio che sta in piedi con lo sputo. È la differenza tra un sistema che cresce e uno che implode. Smettere di credere alle favole, adottare le pratiche di chi sta sul campo e pretendere di *vedere* cosa succede nel software sono i passi per trasformare un costo nascosto in un vantaggio competitivo.

Se il tuo software ti sta facendo passare le notti in bianco, forse il problema non è quello che vedi. È quello che hai deciso di non gestire.