Eccezioni in Python: try, except, else, finally e raise

Gli errori sono solo valori con un brutto carattere

Quando qualcosa va storto in Python (una divisione per zero, la lettura di un file mancante, l'interpretazione di un numero non valido) l'interprete crea un oggetto eccezione e inizia a risalire lo stack delle chiamate finché qualcosa non lo cattura. Se niente lo cattura, il programma termina e stampa un traceback.

Le eccezioni di per sé non sono un male. Sono il modo in cui Python segnala "non posso continuare con questa operazione, ecco perché". Il tuo compito è decidere, caso per caso, da quali sai come riprenderti e quali invece devi lasciar salire.

La forma di base

text = input("Type a number: ")

try:
    number = int(text)
    print(f"Doubled: {number * 2}")
except ValueError:
    print(f"That wasn't a valid number: {text!r}")

• try: apre il blocco di codice rischioso.
• except ValueError: cattura quella specifica eccezione se viene sollevata dentro il try.
• Se non scatta nessuna eccezione, l'except viene saltato del tutto.

Esegui lo snippet con 42: funziona. Eseguilo con hello: parte il gestore.

Catturare eccezioni specifiche

Python ha una gerarchia di tipi di eccezione. Eccone alcune che incontrerai spesso:

• ValueError: un valore era sbagliato in qualche modo (int("abc"), argomenti fuori intervallo).
• TypeError: è stato usato il tipo sbagliato ("hi" + 3).
• KeyError: una chiave di un dict non è stata trovata.
• IndexError: un indice di una sequenza era fuori intervallo.
• FileNotFoundError: un file non esiste.
• ZeroDivisionError: si è tentato di dividere per zero.
• AttributeError: un oggetto non ha l'attributo richiesto.

Cattura quella specifica che sai gestire:

data = {"count": 5}

try:
    print(data["missing"])
except KeyError:
    print("Key not found - using a default.")

Puoi catturare più eccezioni in una sola clausola passando una tupla:

try:
    value = int(input("Number? "))
    result = 10 / value
except (ValueError, ZeroDivisionError) as e:
    print(f"Got bad input: {e}")

Nota as e. Associa l'oggetto eccezione a e, così puoi esaminarne il messaggio o gli attributi.

Evita di catturare tutto

Un except: generico cattura letteralmente qualsiasi cosa, compresi KeyboardInterrupt (il tuo Ctrl-C) e le uscite a livello di sistema. Non usarlo.

except Exception: è un po' meglio, ma resta pericoloso: inghiotte bug che non avevi previsto e nasconde la vera origine dei problemi:

# Non farlo senza un ottimo motivo.
try:
    do_something()
except Exception:
    pass

La mossa giusta è quasi sempre catturare l'eccezione specifica da cui sai come riprenderti. Se un'eccezione inattesa arriva in cima al programma, il traceback ti dice esattamente cosa è andato storto: è una funzionalità, non un difetto.

else e finally

L'istruzione try ha altre due clausole facoltative:

• else viene eseguito se il blocco try è terminato senza sollevare eccezioni.
• finally viene eseguito in ogni caso, eccezione o no.

def parse_line(line):
    try:
        key, value = line.strip().split("=", 1)
    except ValueError:
        print(f"Couldn't parse: {line!r}")
        return None
    else:
        print(f"Parsed: {key} = {value}")
        return (key.strip(), value.strip())
    finally:
        print("Done with this line.")

parse_line("host = localhost")
parse_line("missing equals sign")

else è il posto più pulito per il codice "solo in caso di successo": non vuoi che un blocco try faccia più della parte che può davvero fallire. finally serve per la pulizia che deve avvenire anche se il try fallisce: chiudere una risorsa, rilasciare un lock, ripristinare uno stato.

Sollevare eccezioni tu stesso

Usa raise per segnalare un errore nel tuo codice:

def discount(price, percent):
    if percent < 0 or percent > 100:
        raise ValueError(f"Percent must be 0–100, got {percent}")
    return price * (1 - percent / 100)

print(discount(100, 20))

try:
    discount(100, 150)
except ValueError as e:
    print(f"Caught: {e}")

Scegli un tipo di eccezione adatto a ciò che è andato storto. Prima di definire una tua classe, prova con quelli integrati: ValueError, TypeError, FileNotFoundError.

Definire un'eccezione personalizzata

Quando quelle integrate non esprimono il significato giusto, definisci un'eccezione personalizzata:

class PaymentDeclined(Exception):
    """Raised when a payment provider declines the transaction."""

def charge(amount):
    # Immagina che questo comunichi con un processore di pagamenti.
    if amount > 1000:
        raise PaymentDeclined(f"Declined for ${amount}")
    print(f"Charged ${amount}")

try:
    charge(1500)
except PaymentDeclined as e:
    print("Payment failed:", e)

Eredita da Exception (o da un'eccezione integrata più specifica) e dai alla classe una docstring. Di solito non serve altro. Le eccezioni personalizzate permettono a chi chiama di catturare solo l'errore che ha senso nel suo dominio.

raise ... from ...: eccezioni concatenate

Quando un'eccezione ne scatena un'altra, conserva la catena:

class ConfigError(Exception):
    pass

def load_config(path):
    try:
        with open(path) as f:
            return f.read()
    except FileNotFoundError as e:
        raise ConfigError(f"Missing config at {path}") from e

try:
    load_config("nonexistent.cfg")
except ConfigError as e:
    print("Top-level:", e)
    print("Caused by:", e.__cause__)

from e collega l'errore originale. Quando stampa il traceback, Python li mostra entrambi: il ConfigError emerso in superficie e il FileNotFoundError che l'ha causato. Una traccia del genere è preziosissima durante il debug.

Context manager: il modo più pulito per fare pulizia

finally va bene, ma per risorse come i file un context manager (quello che usa with) è quasi sempre meglio:

# versione con finally
f = open("data.txt")
try:
    data = f.read()
finally:
    f.close()

# versione con with
with open("data.txt") as f:
    data = f.read()

Entrambe sono sicure. La forma con with è più breve e si applica da sola. Ricorri a finally solo quando stai facendo qualcosa che la libreria standard non avvolge già in un context manager.

Quando non catturare

Catturare un'eccezione è una decisione: stai dicendo "questo lo so gestire". Se non sai gestirla, lasciala propagare. Codice come questo è quasi sempre un errore:

try:
    do_work()
except Exception:
    pass  # ignora tutto in silenzio

Zittire gli errori rende invisibili i bug. Meglio un crash rumoroso che andare avanti zoppicando in uno stato incoerente.

Riassumendo

• try/except ti permette di gestire gli errori da cui puoi riprenderti.
• Cattura eccezioni specifiche, non Exception alla cieca.
• raise segnala errori nel tuo codice.
• I blocchi with sostituiscono la maggior parte della pulizia con finally.
• Nel dubbio, lascia propagare l'eccezione.

Prossimo argomento: un giro tra gli errori specifici che Python solleva più spesso (KeyError, ValueError, ModuleNotFoundError e qualche altro) più le abitudini di debug che li risolvono in fretta.