Alcune osservazioni su elementi un pò più approfonditi relativi alla gestione delle eccezioni.

In alternativa alla coppia "except/else" (dove else è opzionale), che gestiscono sia i casi di eccezione che di terminazione normale, si può utilizzare la clausola "finally", che invece interviene in qualunque caso, sia che le cose siano andate lisce, sia che siano scattati errori. Ecco un un esempio:

try:
  faccio_qualcosa()
finally:
   pulizie()

Se si usa la finally, non si possono usare except/else: o si usa l'una o l'altra. Il che è logico, se si considera che except/else gestisce casi con e senza eccezioni, mentre finally le gestisce qualunque caso, con e senza eccezioni.

Le eccezioni infine vengono normalmente sollevate da errori trovati nel codice. Ma, mentre alcune eccezioni vengono effettivamente "create dal nulla" dall'interprete (quando rileva situazioni di errore aritmetico per esempio) la loro origine in generale è legata al fatto che qualcuno le "solleva" quando trova qualcosa che non si aspetta.

Le eccezioni vengono generate quando l'istruzione "raise" le solleva. Il parametro di raise è un oggetto di tipo eccezione. L'unica caratteristica è quella di essere deritati, direttamente o indirettamente, dalla classe Exception. Cosa significhi questo lo vedremo quando approfondiremo la programmazione a oggetti.

Gli oggetti si creano come qualunque altro oggetto Python, chiamando una funzione che lo costruisce. Quindi, se per esempio trovo che il file che mi aspettavo non c'è, sollevo l'eccezione con:

raise IOException("non trovato %s" % file)

Abbiamo detto che l'eccezione sono organizzate in una gerarchia, che è già prevista nella libreria standard. Si può consultare il manuale di riferimento di Python, su www.python.org, per avere un elenco e le loro dipendenze gerarchiche.

La gerarchia standard può comunque essere estesa, creando nuove classi. Queste devono essere derivate da Exception o da una altra eccezione già esistente.