# 8. Errori ed Eccezioni

Finora i messaggi di errore sono stati solo menzionati, ma se hai provato gli esempi probabilmente ne hai visti alcuni. Ci sono (almeno) due tipi distinti di errori: errori di sintassi ed eccezioni.

## 8.1. Errori di Sintassi

Gli errori di sintassi, noti anche come errori di parsing, sono forse il tipo più comune di reclamo che si ottiene mentre si sta ancora imparando Python:

    >>> while True print('Hello world')
      File "<stdin>", line 1
        while True print('Hello world')
                   ^^^^^
    SyntaxError: invalid syntax

The parser repeats the offending line and displays little arrows pointing at the place where the error was detected. Note that this is not always the place that needs to be fixed. In the example, the error is detected at the function `print()`, since a colon (`':'`) is missing just before it.

The file name (`<stdin>` in our example) and line number are printed so you know where to look in case the input came from a file.

## 8.2. Eccezioni

Anche se un’istruzione o un’espressione è sintatticamente corretta, può causare un errore quando si tenta di eseguirla. Gli errori rilevati durante l’esecuzione sono chiamati eccezioni e non sono incondizionatamente fatali: imparerai presto come gestirli nei programmi Python. La maggior parte delle eccezioni non viene gestita dai programmi, tuttavia, e si traduce in messaggi di errore come mostrato qui:

    >>> 10 * (1/0)
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
        10 * (1/0)
              ~^~
    ZeroDivisionError: division by zero
    >>> 4 + spam*3
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
        4 + spam*3
            ^^^^
    NameError: name 'spam' is not defined
    >>> '2' + 2
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
        '2' + 2
        ~~~~^~~
    TypeError: can only concatenate str (not "int") to str

L’ultima linea del messaggio di errore indica cosa è successo. Le eccezioni hanno tipi diversi, e il tipo viene stampato come parte del messaggio: i tipi nell’esempio sono `ZeroDivisionError`, `NameError` e `TypeError`. La stringa stampata come tipo di eccezione è il nome dell’eccezione built-in che si è verificata. Questo è vero per tutte le eccezioni built-in, ma non deve essere vero per le eccezioni definite dall’utente (anche se è una convenzione utile). I nomi delle eccezioni standard sono identificatori built-in (non parole chiave riservate).

La restante parte della linea fornisce dettagli basati sul tipo di eccezione e su cosa l’ha causata.

La parte precedente del messaggio di errore mostra il contesto in cui si è verificata l’eccezione, sotto forma di traccia dello stack. In generale, contiene una traccia dello stack che elenca le linee di origine; tuttavia, non visualizzerà linee lette dall’input standard.

Built-in Exceptions elenca le eccezioni built-in e i loro significati.

## 8.3. Gestione delle Eccezioni

È possibile scrivere programmi che gestiscono eccezioni selezionate. Guarda il seguente esempio, che chiede all’utente un input finché non viene inserito un intero valido, ma consente all’utente di interrompere il programma (usando `Control`-`C` o cosa supporta il sistema operativo); nota che un’interruzione generata dall’utente è segnalata sollevando l’eccezione `KeyboardInterrupt`.

    >>> while True:
    ...     try:
    ...         x = int(input("Please enter a number: "))
    ...         break
    ...     except ValueError:
    ...         print("Oops!  That was no valid number.  Try again...")
    ...

L’istruzione `try` funziona come segue.

- Per prima cosa, viene eseguita la clausola try (l’istruzione o le istruzioni tra le parole chiave `try` e `except`).

- Se non si verifica alcuna eccezione, la clausola except viene saltata e l’esecuzione dell’istruzione `try` è terminata.

- Se si verifica un’eccezione durante l’esecuzione della clausola `try`, il resto della clausola viene saltato. Poi, se il suo tipo corrisponde all’eccezione nominata dopo la parola chiave `except`, viene eseguita la clausola except, e quindi l’esecuzione continua dopo il blocco try/except.

- Se si verifica un’eccezione che non corrisponde all’eccezione nominata nella clausola except, viene passata alle istruzioni `try` esterne; se non viene trovato alcun gestore, è un” eccezione non gestita e l’esecuzione si interrompe con un messaggio di errore.

Un’istruzione `try` può avere più di una clausola except, per specificare gestori per diverse eccezioni. Al massimo verrà eseguito un gestore. I gestori gestiscono solo le eccezioni che si verificano nella corrispondente clausola try, non in altri gestori della stessa istruzione `try`. Una clausola except può nominare più eccezioni come una tupla tra parentesi, per esempio:

    ... except (RuntimeError, TypeError, NameError):
    ...     pass

Una classe in una clausola `except` corrisponde a eccezioni che sono istanze della classe stessa o di una delle sue classi derivate (ma non viceversa — una clausola except che elenca una classe derivata non corrisponde a istanze delle sue classi base). Ad esempio, il seguente codice stamperà B, C, D in quell’ordine:

    class B(Exception):
        pass

    class C(B):
        pass

    class D(C):
        pass

    for cls in [B, C, D]:
        try:
            raise cls()
        except D:
            print("D")
        except C:
            print("C")
        except B:
            print("B")

Nota che se le clausole except fossero invertite (con `except B` prima), avrebbero stampato B, B, B — la prima clausola except che corrisponde viene attivata.

Quando si verifica un’eccezione, essa può avere valori associati, noti anche come argomenti dell’eccezione. La presenza e il tipo degli argomenti dipendono dal tipo di eccezione.

La clausola except può specificare una variabile dopo il nome dell’eccezione. La variabile è legata all’istanza dell’eccezione che tipicamente ha un attributo `args` che memorizza gli argomenti. Per comodità, i tipi di eccezioni built-in definiscono `__str__()` per stampare tutti gli argomenti senza accedere esplicitamente a `.args`.

    >>> try:
    ...     raise Exception('spam', 'eggs')
    ... except Exception as inst:
    ...     print(type(inst))    # the exception type
    ...     print(inst.args)     # arguments stored in .args
    ...     print(inst)          # __str__ allows args to be printed directly,
    ...                          # but may be overridden in exception subclasses
    ...     x, y = inst.args     # unpack args
    ...     print('x =', x)
    ...     print('y =', y)
    ...
    <class 'Exception'>
    ('spam', 'eggs')
    ('spam', 'eggs')
    x = spam
    y = eggs

L’output di `__str__()` dell’eccezione viene stampato come l’ultima parte (“dettaglio”) del messaggio per le eccezioni non gestite.

`BaseException` è la classe base comune di tutte le eccezioni. Uno dei suoi sottosclassi, `Exception`, è la classe base di tutte le eccezioni non fatali. Le eccezioni che non sono sottoclassi di `Exception` non sono tipicamente gestite, perché vengono utilizzate per indicare che il programma dovrebbe terminare. Queste includono `SystemExit` che è sollevata da `sys.exit()` e `KeyboardInterrupt` che è sollevata quando un utente desidera interrompere il programma.

`Exception` può essere utilizzata come un jolly che cattura (quasi) tutto. Tuttavia, è buona pratica essere il più specifici possibile con i tipi di eccezioni che intendiamo gestire, e permettere a qualsiasi eccezione inattesa di propagarsi.

Il pattern più comune per la gestione di `Exception` è stamparla o registrarla e poi rilanciarla (consentendo a un chiamante di gestire l’eccezione altrettanto):

    import sys

    try:
        f = open('myfile.txt')
        s = f.readline()
        i = int(s.strip())
    except OSError as err:
        print("OS error:", err)
    except ValueError:
        print("Could not convert data to an integer.")
    except Exception as err:
        print(f"Unexpected {err=}, {type(err)=}")
        raise

L’istruzione `try` … `except` ha una clausola else opzionale, che, quando presente, deve seguire tutte le clausole except. È utile per il codice che deve essere eseguito se la clausola try non solleva un’eccezione. Per esempio:

    for arg in sys.argv[1:]:
        try:
            f = open(arg, 'r')
        except OSError:
            print('cannot open', arg)
        else:
            print(arg, 'has', len(f.readlines()), 'lines')
            f.close()

L’uso della clausola `else` è migliore che aggiungere codice ulteriore alla clausola `try` perché evita di catturare accidentalmente un’eccezione che non è stata sollevata dal codice protetto dall’istruzione `try` … `except`.

I gestori delle eccezioni non gestiscono solo le eccezioni che si verificano immediatamente nella clausola try, ma anche quelle che si verificano all’interno delle funzioni che vengono chiamate (anche indirettamente) nella clausola try. Per esempio:

    >>> def this_fails():
    ...     x = 1/0
    ...
    >>> try:
    ...     this_fails()
    ... except ZeroDivisionError as err:
    ...     print('Handling run-time error:', err)
    ...
    Handling run-time error: division by zero

## 8.4. Sollevare Eccezioni

L’istruzione `raise` permette al programmatore di forzare il verificarsi di una specifica eccezione. Per esempio:

    >>> raise NameError('HiThere')
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
        raise NameError('HiThere')
    NameError: HiThere

L’unico argomento per `raise` indica l’eccezione da sollevare. Questo deve essere o un’istanza di eccezione o una classe di eccezione (una classe che deriva da `BaseException`, come `Exception` o una delle sue sottoclassi). Se viene passata una classe di eccezione, verrà istanziata implicitamente chiamando il suo costruttore senza argomenti:

    raise ValueError  # shorthand for 'raise ValueError()'

Se è necessario determinare se un’eccezione è stata sollevata ma non si intende gestirla, una forma più semplice dell’istruzione `raise` consente di rilanciare l’eccezione:

    >>> try:
    ...     raise NameError('HiThere')
    ... except NameError:
    ...     print('An exception flew by!')
    ...     raise
    ...
    An exception flew by!
    Traceback (most recent call last):
      File "<stdin>", line 2, in <module>
        raise NameError('HiThere')
    NameError: HiThere

## 8.5. Collegamento delle Eccezioni

Se si verifica un’eccezione non gestita all’interno di una sezione `except`, avrà l’eccezione che viene gestita allegata e inclusa nel messaggio di errore:

    >>> try:
    ...     open("database.sqlite")
    ... except OSError:
    ...     raise RuntimeError("unable to handle error")
    ...
    Traceback (most recent call last):
      File "<stdin>", line 2, in <module>
        open("database.sqlite")
        ~~~~^^^^^^^^^^^^^^^^^^^
    FileNotFoundError: [Errno 2] No such file or directory: 'database.sqlite'

    During handling of the above exception, another exception occurred:

    Traceback (most recent call last):
      File "<stdin>", line 4, in <module>
        raise RuntimeError("unable to handle error")
    RuntimeError: unable to handle error

Per indicare che un’eccezione è una diretta conseguenza di un’altra, l’istruzione `raise` permette una clausola opzionale `from`:

    # exc must be exception instance or None.
    raise RuntimeError from exc

Questo può essere utile quando si stanno trasformando le eccezioni. Per esempio:

    >>> def func():
    ...     raise ConnectionError
    ...
    >>> try:
    ...     func()
    ... except ConnectionError as exc:
    ...     raise RuntimeError('Failed to open database') from exc
    ...
    Traceback (most recent call last):
      File "<stdin>", line 2, in <module>
        func()
        ~~~~^^
      File "<stdin>", line 2, in func
    ConnectionError

    The above exception was the direct cause of the following exception:

    Traceback (most recent call last):
      File "<stdin>", line 4, in <module>
        raise RuntimeError('Failed to open database') from exc
    RuntimeError: Failed to open database

Consente anche di disabilitare il collegamento automatico delle eccezioni utilizzando l’idioma `from None`:

    >>> try:
    ...     open('database.sqlite')
    ... except OSError:
    ...     raise RuntimeError from None
    ...
    Traceback (most recent call last):
      File "<stdin>", line 4, in <module>
        raise RuntimeError from None
    RuntimeError

Per ulteriori informazioni sulla meccanica del collegamento, vedi Built-in Exceptions.

## 8.6. Eccezioni Definite dall’Utente

I programmi possono nominare le proprie eccezioni creando una nuova classe di eccezione (vedi Classi per ulteriori informazioni sulle classi Python). Le eccezioni devono essere tipicamente derivate dalla classe `Exception`, direttamente o indirettamente.

Si possono definire classi di eccezione che fanno qualsiasi cosa possa fare qualsiasi altra classe, ma di solito vengono mantenute semplici, spesso offrendo solo un numero di attributi che consentono di estrarre informazioni sull’errore dai gestori per l’eccezione.

La maggior parte delle eccezioni è definita con nomi che terminano in «Error», simili alla denominazione delle eccezioni standard.

Molti moduli standard definiscono le proprie eccezioni per segnalare errori che possono verificarsi nelle funzioni che definiscono.

## 8.7. Definizione di Azioni di Pulizia

L’istruzione `try` ha un’altra clausola opzionale che è intesa a definire azioni di pulizia che devono essere eseguite in tutte le circostanze. Per esempio:

    >>> try:
    ...     raise KeyboardInterrupt
    ... finally:
    ...     print('Goodbye, world!')
    ...
    Goodbye, world!
    Traceback (most recent call last):
      File "<stdin>", line 2, in <module>
        raise KeyboardInterrupt
    KeyboardInterrupt

Se è presente una clausola `finally`, la clausola `finally` verrà eseguita come ultimo compito prima che l’istruzione `try` completi. La clausola `finally` viene eseguita sia che l’istruzione `try` produca o meno un’eccezione. I seguenti punti discutono casi più complessi quando si verifica un’eccezione:

- Se si verifica un’eccezione durante l’esecuzione della clausola `try`, l’eccezione può essere gestita da una clausola `except`. Se l’eccezione non è gestita da una clausola `except`, l’eccezione viene rilanciata dopo che la clausola `finally` è stata eseguita.

- Un’eccezione potrebbe verificarsi durante l’esecuzione di una clausola `except` o `else`. Anche in questo caso, l’eccezione viene rilanciata dopo che la clausola `finally` è stata eseguita.

- If the `finally` clause executes a `break`, `continue` or `return` statement, exceptions are not re-raised. This can be confusing and is therefore discouraged. From version 3.14 the compiler emits a `SyntaxWarning` for it (see PEP 765).

- Se l’istruzione `try` raggiunge un’istruzione `break`, `continue` o `return`, la clausola `finally` verrà eseguita appena prima dell’esecuzione dell’istruzione `break`, `continue` o `return`.

- If a `finally` clause includes a `return` statement, the returned value will be the one from the `finally` clause’s `return` statement, not the value from the `try` clause’s `return` statement. This can be confusing and is therefore discouraged. From version 3.14 the compiler emits a `SyntaxWarning` for it (see PEP 765).

Per esempio:

    >>> def bool_return():
    ...     try:
    ...         return True
    ...     finally:
    ...         return False
    ...
    >>> bool_return()
    False

Un esempio più complicato:

    >>> def divide(x, y):
    ...     try:
    ...         result = x / y
    ...     except ZeroDivisionError:
    ...         print("division by zero!")
    ...     else:
    ...         print("result is", result)
    ...     finally:
    ...         print("executing finally clause")
    ...
    >>> divide(2, 1)
    result is 2.0
    executing finally clause
    >>> divide(2, 0)
    division by zero!
    executing finally clause
    >>> divide("2", "1")
    executing finally clause
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
        divide("2", "1")
        ~~~~~~^^^^^^^^^^
      File "<stdin>", line 3, in divide
        result = x / y
                 ~~^~~
    TypeError: unsupported operand type(s) for /: 'str' and 'str'

Come puoi vedere, la clausola `finally` viene eseguita in ogni caso. L’eccezione `TypeError` sollevata dividendo due stringhe non è gestita dalla clausola `except` e quindi rilanciata dopo che la clausola `finally` è stata eseguita.

Nelle applicazioni del mondo reale, la clausola `finally` è utile per rilasciare risorse esterne (come file o connessioni di rete), indipendentemente dal successo dell’uso delle risorse.

## 8.8. Azioni di Pulizia Predefinite

Alcuni oggetti definiscono azioni di pulizia standard da intraprendere quando l’oggetto non è più necessario, indipendentemente dal fatto che l’operazione che usa l’oggetto sia riuscita o fallita. Guarda il seguente esempio, che tenta di aprire un file e stampare il suo contenuto sullo schermo.

    for line in open("myfile.txt"):
        print(line, end="")

Il problema con questo codice è che lascia il file aperto per un tempo indeterminato dopo che questa parte del codice ha terminato l’esecuzione. Questo non è un problema negli script semplici, ma può essere un problema per applicazioni più grandi. L’istruzione `with` consente agli oggetti come i file di essere usati in modo tale da garantire che siano sempre puliti rapidamente e correttamente.

    with open("myfile.txt") as f:
        for line in f:
            print(line, end="")

Dopo che l’istruzione è stata eseguita, il file f è sempre chiuso, anche se si è verificato un problema durante l’elaborazione delle linee. Gli oggetti che, come i file, forniscono azioni di pulizia predefinite indicheranno ciò nella loro documentazione.

## 8.9. Sollevare e Gestire Eccezioni Multiple e Non Correlate

Ci sono situazioni in cui è necessario segnalare diverse eccezioni che si sono verificate. Questo è spesso il caso nei framework di concorrenza, quando diversi compiti possono aver fallito in parallelo, ma ci sono anche altri casi d’uso in cui è desiderabile continuare l’esecuzione e raccogliere più errori piuttosto che sollevare la prima eccezione.

L’eccezione built-in `ExceptionGroup` avvolge una lista di istanze di eccezione in modo tale che possano essere sollevate insieme. È un’eccezione a sé stante, quindi può essere catturata come qualsiasi altra eccezione.

    >>> def f():
    ...     excs = [OSError('error 1'), SystemError('error 2')]
    ...     raise ExceptionGroup('there were problems', excs)
    ...
    >>> f()
      + Exception Group Traceback (most recent call last):
      |   File "<stdin>", line 1, in <module>
      |     f()
      |     ~^^
      |   File "<stdin>", line 3, in f
      |     raise ExceptionGroup('there were problems', excs)
      | ExceptionGroup: there were problems (2 sub-exceptions)
      +-+---------------- 1 ----------------
        | OSError: error 1
        +---------------- 2 ----------------
        | SystemError: error 2
        +------------------------------------
    >>> try:
    ...     f()
    ... except Exception as e:
    ...     print(f'caught {type(e)}: e')
    ...
    caught <class 'ExceptionGroup'>: e
    >>>

Usando `except*` invece di `except`, possiamo gestire selettivamente solo le eccezioni nel gruppo che corrispondono a un certo tipo. Nell’esempio seguente, che mostra un gruppo di eccezioni annidato, ogni clausola `except*` estrae dal gruppo le eccezioni di un certo tipo lasciando che tutte le altre eccezioni si propaghino ad altre clausole e, infine, vengano rilanciate.

    >>> def f():
    ...     raise ExceptionGroup(
    ...         "group1",
    ...         [
    ...             OSError(1),
    ...             SystemError(2),
    ...             ExceptionGroup(
    ...                 "group2",
    ...                 [
    ...                     OSError(3),
    ...                     RecursionError(4)
    ...                 ]
    ...             )
    ...         ]
    ...     )
    ...
    >>> try:
    ...     f()
    ... except* OSError as e:
    ...     print("There were OSErrors")
    ... except* SystemError as e:
    ...     print("There were SystemErrors")
    ...
    There were OSErrors
    There were SystemErrors
      + Exception Group Traceback (most recent call last):
      |   File "<stdin>", line 2, in <module>
      |     f()
      |     ~^^
      |   File "<stdin>", line 2, in f
      |     raise ExceptionGroup(
      |     ...<12 lines>...
      |     )
      | ExceptionGroup: group1 (1 sub-exception)
      +-+---------------- 1 ----------------
        | ExceptionGroup: group2 (1 sub-exception)
        +-+---------------- 1 ----------------
          | RecursionError: 4
          +------------------------------------
    >>>

Nota che le eccezioni annidate in un gruppo di eccezioni devono essere istanze, non tipi. Questo perché in pratica le eccezioni sarebbero tipicamente quelle che sono state già sollevate e catturate dal programma, seguendo il seguente pattern:

    >>> excs = []
    ... for test in tests:
    ...     try:
    ...         test.run()
    ...     except Exception as e:
    ...         excs.append(e)
    ...
    >>> if excs:
    ...    raise ExceptionGroup("Test Failures", excs)
    ...

## 8.10. Arricchire le Eccezioni con Note

Quando un’eccezione viene creata per essere sollevata, viene solitamente inizializzata con informazioni che descrivono l’errore verificatosi. Ci sono casi in cui è utile aggiungere informazioni dopo che l’eccezione è stata catturata. Per questo scopo, le eccezioni hanno un metodo `add_note(note)` che accetta una stringa e la aggiunge alla lista di note dell’eccezione. Il rendering standard del traceback include tutte le note, nell’ordine in cui sono state aggiunte, dopo l’eccezione.

    >>> try:
    ...     raise TypeError('bad type')
    ... except Exception as e:
    ...     e.add_note('Add some information')
    ...     e.add_note('Add some more information')
    ...     raise
    ...
    Traceback (most recent call last):
      File "<stdin>", line 2, in <module>
        raise TypeError('bad type')
    TypeError: bad type
    Add some information
    Add some more information
    >>>

Per esempio, quando si raccolgono eccezioni in un gruppo di eccezioni, potremmo voler aggiungere informazioni di contesto per gli errori individuali. Nel seguente esempio, ogni eccezione nel gruppo ha una nota che indica quando si è verificato l’errore.

    >>> def f():
    ...     raise OSError('operation failed')
    ...
    >>> excs = []
    >>> for i in range(3):
    ...     try:
    ...         f()
    ...     except Exception as e:
    ...         e.add_note(f'Happened in Iteration {i+1}')
    ...         excs.append(e)
    ...
    >>> raise ExceptionGroup('We have some problems', excs)
      + Exception Group Traceback (most recent call last):
      |   File "<stdin>", line 1, in <module>
      |     raise ExceptionGroup('We have some problems', excs)
      | ExceptionGroup: We have some problems (3 sub-exceptions)
      +-+---------------- 1 ----------------
        | Traceback (most recent call last):
        |   File "<stdin>", line 3, in <module>
        |     f()
        |     ~^^
        |   File "<stdin>", line 2, in f
        |     raise OSError('operation failed')
        | OSError: operation failed
        | Happened in Iteration 1
        +---------------- 2 ----------------
        | Traceback (most recent call last):
        |   File "<stdin>", line 3, in <module>
        |     f()
        |     ~^^
        |   File "<stdin>", line 2, in f
        |     raise OSError('operation failed')
        | OSError: operation failed
        | Happened in Iteration 2
        +---------------- 3 ----------------
        | Traceback (most recent call last):
        |   File "<stdin>", line 3, in <module>
        |     f()
        |     ~^^
        |   File "<stdin>", line 2, in f
        |     raise OSError('operation failed')
        | OSError: operation failed
        | Happened in Iteration 3
        +------------------------------------
    >>>