La gestione di file e flussi in Java: note introduttive

Università degli Studi di Palermo Facoltà di Ingegneria La gestione di file e flussi in Java: note introduttive Edoardo Ardizzone & Riccardo Rizzo Appunti per il corso di Fondamenti di Informatica A.A. 2005-2006 Corso di Laurea in Ingegneria Informatica

Introduzione alla gestione delle eccezioni Se durante l esecuzione di un metodo si verifica una situazione di errore capace di alterare il normale flusso di esecuzione del programma, è buona norma tentare di gestirla, trasferendo il controllo dal punto in cui l errore viene individuato ad un appropriato gestore, ossia un gruppo di istruzioni capaci di ripristinare una situazione di funzionamento corretto o almeno di fornire all utente informazioni sufficienti a capire cosa sta avvenendo. Non necessariamente questo gestore coincide con il metodo chiamante. Per esempio, nelle operazioni di accesso ad un file possono verificarsi delle condizioni che impediscono la corretta esecuzione delle operazioni desiderate: il file specificato non esiste, il disco rigido è pieno e non permette di scrivere, il file sul quale si vuole scrivere è protetto in scrittura, etc. Non è detto che il metodo che ha richiesto l accesso al file sappia come fronteggiare tali situazioni. Una soluzione classica al problema della gestione degli errori prevede la restituzione di informazioni sulla corretta (o meno) conclusione delle operazioni previste da un metodo attraverso un valore di ritorno convenzionale (per esempio un intero positivo o negativo, per indicare il successo o il fallimento). Tale approccio però può dare diversi problemi: il modulo chiamante può non essere attrezzato per controllare il valore di ritorno, oppure può non essere competente, cioè in grado di adottare una soluzione efficace. Per esempio, se si verifica un errore dovuto alla conclusione inattesa dei dati letti da un file durante l esecuzione di un metodo di libreria come next() della classe Scanner, molto probabilmente il metodo che ha invocato next() non ha informazioni sufficienti per il ripristino di una condizione di funzionamento corretta. Nella documentazione Java, una eccezione (o evento eccezionale) è definita come un evento che, verificandosi durante l esecuzione di un programma, disarticola il normale flusso di esecuzione delle istruzioni del programma [1]. Java fornisce un meccanismo efficiente e flessibile per la gestione delle eccezioni: quando in un metodo si verifica un errore, il metodo crea un oggetto e lo passa al sistema Java. Tale oggetto, chiamato oggetto eccezione, contiene informazioni sull errore, come il tipo dell errore stesso e lo stato del programma al suo verificarsi. La creazione dell oggetto eccezione e il suo passaggio al sistema Java costituiscono il lancio dell eccezione. Dopo che un metodo ha lanciato (o sollevato) una eccezione, il sistema Java tenta di trovare qualcosa di utile per la gestione dell eccezione. Questa ricerca avviene nella pila delle attivazioni dei metodi (call stack). Un esempio di call stack è mostrato in fig. 1. 2 Fig. 1 Call stack [1] Fig. 2 Ricerca di un gestore appropriato [1]

Il sistema Java cerca nella pila delle attivazioni un metodo contenente un blocco di istruzioni capace di gestire l eccezione, cioè il gestore della eccezione (exception handler). La ricerca inizia nel metodo in cui si è verificato l errore e continua nella pila delle attivazioni nell ordine inverso a quello delle invocazioni di metodo. Se trova un gestore appropriato, il sistema Java gli passa l eccezione. Un gestore è considerato appropriato se il tipo dell eccezione sollevata è compatibile con il tipo di eccezioni che il gestore può trattare. In questo caso, il gestore cattura l eccezione. Se invece il sistema Java, dopo aver effettuato una ricerca esaustiva in tutti i metodi dello stack, non trova un exception handler appropriato (è l esempio di fig. 2), il programma termina. Riassumendo, se in una porzione di codice potenzialmente problematica (opportunamente inserita, come si vedrà, all'interno di uno specifico blocco) si solleva una eccezione, il controllo viene passato ad un altro blocco (se esiste) capace di gestirla nella maniera opportuna. Il programmatore deve scrivere solo il codice di controllo che verifica la situazione anomala e sollevare la corrispondente eccezione. Le eccezioni vengono infatti gestite dal sistema Java in modo da non potere essere trascurate, attraverso una tecnica di rilancio delle eccezioni stesse, fino alla cattura da parte di un gestore competente o alla fine del programma. Questa strategia può essere riassunta dalla frase lanciare presto, catturare tardi. Naturalmente, prima che una eccezione possa essere catturata, deve essere sollevata, o da un metodo scritto dal programmatore, o da un metodo presente in un package scritto da altri programmatori, o da un metodo delle Java API, o dallo stesso sistema Java. Indipendentemente da quale sia la porzione di codice che solleva l eccezione, il lancio avviene con la clausola throw. E importante notare ancora che le eccezioni in Java sono oggetti. Ne esistono predefinite, raggruppate per classi nelle Java API, in modo da permettere ai programmi di distinguere tra diversi tipi di errori, ma il programmatore è comunque libero di definire nuove classi di eccezioni, per rappresentare in modo più preciso i problemi che possono presentarsi nel nuovo codice da lui scritto. Tutte le classi di eccezioni discendono dalla classe Throwable del package java.lang, secondo la struttura gerarchica parzialmente mostrata in fig. 3. Le sue sottoclassi dirette sono Exception, che raggruppa eccezioni sollevate quando si verificano errori considerati recuperabili da un normale programma utente, come file non trovato o indice di array fuori dai limiti, e Error che invece fa riferimento a gravi problemi relativi al funzionamento della macchina virtuale, tali da provocare situazioni normalmente considerate irrecuperabili dai programmi comuni. Le eccezioni della classe Error e delle sue sottoclassi sono lanciate direttamente dalla JVM e provocano la fine del programma. Da ora in poi ci si concentrerà pertanto solo sulle eccezioni appartenenti alla classe Exception e alle sue sottoclassi. 3

Object Throwable Error Exception IOException ClassNotFound Exception RunTime Exception EOF Exception IllegalArgument Exception NumberFormat Exception FileNotFound Exception Arithmetic Exception UnknownHost Exception IndexOutOfBounds Exception ArrayIndexOutOf BoundsException Fig. 3 Gerarchia delle classi di eccezioni (parziale) Un semplice esempio per illustrare quanto il programmatore deve fare per il lancio di una eccezione è il seguente. Ricordando l applicazione sulla gestione dei conti correnti bancari vista in altra parte del corso, si supponga di voler modificare il metodo preleva della classe ContoCorrente, riportato di seguito per comodità: public class ContoCorrente. public void preleva( double unasomma ) //preleva denaro dal conto corrente se possibile, altrimenti stampa messaggio if (saldo >= unasomma) saldo = saldo - unasomma; 4

else System.out.printf ("Impossibile prelevare %.2f dal conto corrente %d",unasomma, codice);. Si vuole modificare il metodo preleva in modo che, se l importo del prelievo risulta troppo elevato, invece della semplice stampa di un messaggio di errore, venga lanciata una eccezione. Che tipo di eccezione? Conviene prima di tutto cercarne una appropriata fra le classi di eccezioni disponibili nelle Java API. Esaminando la fig. 3, la sottoclasse IllegalArgumentException sembra utilizzabile, dato che proprio è l argomento passato al metodo a provocare la situazione anomala. Supponendo quindi di voler lanciare, se necessario, una eccezione di questo tipo, il metodo può essere riscritto nel modo seguente: 5 public class ContoCorrente. public void preleva( double unasomma ) //preleva denaro dal conto corrente se possibile, altrimenti lancia eccezione if (saldo < unasomma) IllegalArgumentException e = new IllegalArgumentException( Importo superiore al saldo ); throw e; saldo = saldo - unasomma;. E ovviamente anche possibile lanciare direttamente l oggetto restituito dall operatore new: if (saldo < unasomma) throw new IllegalArgumentException( Importo superiore al saldo ); Il lancio dell eccezione conclude l esecuzione del metodo (come se fosse stata eseguita una istruzione return), e il controllo passa non al metodo chiamante ma al gestore dell eccezione, se esiste, come si vedrà tra breve. Esistono due categorie di eccezioni in Java: le eccezioni controllate (checked) e le eccezioni non controllate (unchecked). Quando in un programma è presente un metodo che può lanciare una eccezione controllata, il compilatore verifica che sia presente nel programma un gestore dell eccezione, oppure che sia comunque evidente la volontà del programmatore di reagire all eventuale sollevazione dell eccezione, in modo che l eccezione non possa essere ignorata. Ad esempio, le sottoclassi di IOException sono relative ad eccezioni controllate. Se il gestore non esiste, o se la volontà del programmatore non è evidente, il compilatore segnala un errore. Viceversa, il compilatore non effettua alcuna verifica in relazione alle eccezioni non controllate. Sono non controllate tutte le eccezioni appartenenti a sottoclassi di RunTimeExceptions o di Error. La motivazione di questa differenza di trattamento, peraltro molto discussa nella comunità Java, è la seguente. Una eccezione controllata descrive un problema che si ritiene possa verificarsi indipendentemente dalla capacità o dalla attenzione del programmatore, come per esempio la fine dei dati di un file dovuta ad un errore del disco o alla interruzione di una connessione di rete. In tal caso, è obbligatorio per il programmatore specificare come si deve intervenire per ovviare ad una tale condizione di errore. Viceversa, le eccezioni non controllate sono relative ad errori del programmatore: una NumberFormatException o una ArithmeticException derivano sicuramente

da errori del codice che il programmatore dovrebbe evitare senza ricorrere alla installazione di un gestore di eccezioni. Riassumendo, è obbligatorio per il programmatore gestire le eccezioni controllate, relative a situazioni che sfuggono alla sua capacità di controllo o di trattamento, mentre può essere da lui trascurata la gestione delle eccezioni non controllate, relative a errori di programmazione. Questa scelta rende tra l altro più agevole il compito dei programmatori inesperti, anche in relazione all elevata probabilità di verificarsi tipica degli errori di run time. Come si è visto, rientrano tra le eccezioni controllate tutte quelle (sottoclasse IOExceptions e discendenti) normalmente possibili nella gestione di dati in ingresso o in uscita, tipicamente quando il programma interagisce con file e flussi, cioè con entità esterne al programma stesso, quindi passibili di errori non imputabili al programmatore. Per esempio, la classe Scanner può essere utilizzata per leggere dati da un file, nel modo seguente: String fname = ; FileReader r = new FileReader(fname); Scanner in = new Scanner(r); Una stringa contenente il nome del file da leggere viene passata al costruttore di FileReader, in modo da istanziare un oggetto, r, che è possibile utilizzare per costruire un oggetto Scanner dal quale leggere (come si è fatto finora per il dispositivo standard di ingresso), utilizzando i metodi messi a disposizione dalla classe Scanner (se ne veda la descrizione nella documentazione delle Java API). Anche in un caso semplice come questo possono svilupparsi situazioni anomale. Il costruttore di FileReader, per esempio, può lanciare una eccezione (controllata) FileNotFoundException. Quindi bisogna o usare i blocchi try catch per gestire direttamente la situazione (nel modo che verrà illustrato tra breve) o rendere noto al compilatore, più semplicemente ma anche più ragionevolmente (dato che molto probabilmente un metodo che legge dati di input non sa come comportarsi se il file non esiste) che si è consapevoli del problema e che si vuole soltanto che il metodo termini la sua esecuzione nel caso in cui l eccezione sia sollevata, rilanciando l eccezione. Per fare questo, basta aggiungere alla prima riga della dichiarazione di metodo lo specificatore throws, seguito dal tipo di eccezione che si vuole rilanciare, come in: public class. public void myread (String fname) throws FileNotFoundException FileReader r = new FileReader(fname); Scanner in = new Scanner(r);. Si noti che il tipo di eccezione sollevabile diviene in tal modo parte integrante dell interfaccia pubblica del metodo myread. Ciò significa che qualunque cliente della classe che contiene il metodo myread sa di potere trovarsi a gestire una eccezione di questo tipo, allo stesso modo del programmatore che usa la classe FileReader delle Java API (e infatti la stessa clausola throws, seguita dallo stesso tipo di eccezione, completa la prima riga della descrizione del costruttore di FileReader nella documentazione di tale classe). Questo meccanismo consente all eccezione di raggiungere, purché esista, un metodo capace di intraprendere una efficace azione di recupero, evitando questo compito ai metodi di livello più basso. Se il metodo può lanciare più eccezioni controllate di tipi diversi, basta indicarli separati da virgole, per esempio: 6

public void myread (String fname) throws FileNotFoundException,EOFException Se una eccezione lanciata non ha un gestore rintracciabile nella pila delle attivazioni, come si è detto, il programma termina con un generico messaggio di errore. Per evitare ciò, un programma scritto professionalmente deve prevedere la presenza di gestori per tutte le eccezioni possibili, in modo da evitare brusche conclusioni, normalmente poco gradite agli utenti. Si pensi ad un browser puntato su una pagina web che a un certo punto diventa non accessibile (perché non più disponibile, perché la connessione di rete si è interrotta, etc.). Certamente l utente non si aspetta la fine dell esecuzione del browser, si aspetta invece che il browser si comporti in modo più amichevole (come fanno la maggior parte dei browser reali), cioè segnali la condizione di errore e resti in vita, consentendo all utente di continuare ad operare. Come accennato in precedenza, un gestore di eccezioni si installa utilizzando gli enunciati try catch. Un blocco di codice che contiene le istruzioni che possono provocare il lancio di una eccezione è preceduto dalla parola chiave try, mentre ogni blocco destinato a gestire una delle eccezioni è preceduto dalla parola chiave catch, come nell esempio seguente: try //gruppo di istruzioni //capaci di generare eccezioni catch (IOException e) //gruppo di linee capaci //di gestire una eccezione di tipo //IOException sollevata //nel blocco try precedente catch (NumberFormatException e) //gruppo di linee capaci //di gestire una eccezione di tipo //NumberFormatException sollevata //nel blocco try precedente Un esempio di operazione che può generare eccezioni è la lettura da input attraverso la variabile System.in che definisce il dispositivo standard di input. La lettura di byte da input è eseguita nell esempio seguente utilizzando il metodo read (che restituisce un intero) della classe Reader del package java.io: import java.io.*; public class EsempioEccezione public static void main (String args[]) char ch; try System.out.print( Lettura dall'input ); ch=(char) System.in.read(); System.out.println(ch); catch (IOException e) System.out.println( Errore in input ); //fine classe EsempioEccezione 7

Il metodo read (si veda la documentazione delle Java API) può sollevare eccezioni di classe IOException. Se durante l esecuzione del metodo read (o in qualunque altro punto del blocco try) viene sollevata una eccezione di questo tipo, le restanti istruzioni del blocco try non vengono eseguite, e il controllo passa al blocco catch, che è stato impostato per catturare proprio questo tipo di eccezioni. Se non vengono sollevate eccezioni, il blocco try termina normalmente e il blocco catch non viene eseguito. Se durante l esecuzione del blocco try viene sollevata una eccezione di tipo diverso da IOException, il blocco catch non è in grado di intercettarla, e l eccezione non è gestita. Nell'esempio che segue, le istruzioni all'interno del blocco try possono generare eccezioni di due tipi: try BufferedReader in = new BufferedReader(new InputStreamReader(System.in)); System.out.println( Quanti anni hai? ); String inputline = in.readline(); int age = Integer.parseInt(inputLine); age++; System.out.println( L anno venturo avrai + age + anni ); catch(ioexception e ) System.out.println( Errore di input/output + e); catch(numberformatexception e ) System.out.println( L input non era un numero ); Le eccezioni che possono essere sollevate sono di due tipi, in quanto il metodo readline può dar luogo ad una eccezione (controllata) IOException, mentre Integer.parseInt può generare una eccezione (non controllata) NumberFormatException. Se si verifica effettivamente un eccezione, il resto delle istruzioni del blocco try viene saltato e il controllo passa alla clausola catch corrispondente. Le azioni previste dai blocchi catch dell esempio precedente si limitano ad informare l utente della causa del problema. Sarebbero invece opportune delle azioni che permettano l effettivo ripristino del programma, per esempio consentendo all utente di reinserire i dati, come si vedrà più avanti. In particolare, il primo blocco catch utilizza una chiamata (implicita) al metodo tostring() della classe IOException (in realtà ereditato dalla classe Throwable), che fornisce una descrizione in forma di stringa dell errore che si è verificato. Oltre al metodo tostring(), sono da segnalare, per tutte le classi di eccezioni definite nelle Java API, i metodi printstacktrace() e getmessage(), anch essi ereditati dalla classe Throwable, che permettono di ottenere, rispettivamente, un elenco della catena di invocazioni di metodi che ha portato al lancio della eccezione e la stringa contenente il messaggio fornito come argomento al costruttore dell oggetto eccezione. E da notare, inoltre, che, data la struttura gerarchica delle classi di eccezioni (si veda la fig. 3), un blocco catch cattura qualunque eccezione della classe specificata o delle sue sottoclassi. Se per esempio nel blocco try dell esempio precedente fossero presenti istruzioni capaci di sollevare una eccezione EOFException, essa verrebbe catturata dal primo blocco catch. Se all interno di un blocco try sono presenti istruzioni che devono essere comunque eseguite, indipendentemente dall eventuale precedente lancio di una eccezione, esse vanno inserite all interno di una clausola finally, come nell esempio seguente: 8

FileReader r = new FileReader (fname); try Scanner in = new Scanner( r ); // una o più operazioni sul file finally r.close(); Se l esecuzione si svolge normalmente, l istruzione di chiusura del file (metodo close()) viene regolarmente eseguita dopo la fine delle operazioni sul file. Se viceversa durante una di queste operazioni viene lanciata una eccezione, la clausola finally viene comunque eseguita, prima di passare l eccezione al suo gestore, e il file viene chiuso. Se l operazione di chiusura avesse fatto parte del blocco try, non sarebbe stata eseguita in presenza di una eccezione, e il file sarebbe rimasto aperto. Qualora nessuna delle eccezioni predefinite descriva una particolare condizione di errore, come si è detto, il programmatore può definire una propria classe di eccezioni. Riprendendo ancora una volta l esempio del conto corrente bancario, si supponga di volere utilizzare una nuova eccezione InsufficientBalanceException nel caso in cui l importo del prelievo sia superiore a quello del saldo. Il metodo preleva potrebbe essere riscritto nel modo seguente: public void preleva( double unasomma ) //preleva denaro dal conto corrente se possibile, altrimenti lancia eccezione if (saldo < unasomma) InsuffientBalanceException e = new InsufficientBalanceException( Prelievo di + unasomma + superiore al saldo di + saldo); throw e; saldo = saldo - unasomma; Naturalmente occorre definire la nuova eccezione prima di utilizzarla. La prima scelta da compiere è se debba trattarsi di una eccezione controllata o non controllata. Aderendo alla filosofia adottata dai progettisti Java, una eccezione progettata dal programmatore dovrebbe essere non controllata, se riguarda una potenziale situazione di errore generata all interno dello stesso programma. Nell esempio del conto corrente bancario, l errore potrebbe infatti essere evitato controllando l ammontare del saldo prima dell invocazione del metodo preleva. Una eccezione non controllata può essere definita estendendo la classe RunTimeException o una delle sue sottoclassi: public class InsufficientBalanceException extends RunTimeException public InsufficientBalanceException() // costruttore vuoto public InsufficientBalanceException (String message) super(message); 9

Si può notare la presenza di due costruttori: uno senza argomenti, l altro che accetta una stringa destinata a contenere un messaggio che descrive la natura dell errore (è il messaggio recuperabile, una volta che l eccezione sia stata lanciata, con il metodo getmessage, che la nuova eccezione eredita da Throwable). Questa soluzione è normalmente adottata anche per le eccezioni predefinite. Si noti anche l uso della parola riservata super, come prima istruzione del costruttore, che effettua una chiamata esplicita al costruttore della superclasse, necessaria per impostare correttamente la variabile di istanza, ereditata dalla superclasse, contenente il messaggio. Si analizzerà adesso un esempio completo di programma con gestione di eccezioni, sia standard sia definite dall utente, tratto da [2]. Il programma deve leggere un file, il cui nome è richiesto all utente, contenente numeri reali, disposti uno per riga, a partire dalla seconda riga, mentre il numero dei dati contenuti nel file è specificato nella prima riga. In un caso del genere, esistono almeno due tipiche possibilità di errore: il file potrebbe non esistere, e i dati potrebbero essere scritti in un formato errato o comunque diverso da quello previsto. Conviene suddividere l analisi particolareggiata di queste condizioni di errore in due parti, relative rispettivamente alla individuazione dell errore, e quindi al lancio della corrispondente eccezione, e alla azione di ripristino, cioè alla cattura dell eccezione. Per quanto riguarda la fase di individuazione, si è già visto che un file può essere aperto passando la stringa contenente il suo nome al costruttore di FileReader, che lancia una eccezione FileNotFoundException se il file non esiste. Dopo la lettura dei dati, al momento della chiusura del file il metodo close di FileReader può a sua volta lanciare una IOException se incontra un problema. Entrambe queste eccezioni sono già definite nelle Java API e sono controllate, per cui devono essere gestite dal programma utilizzando appropriati blocchi try catch. Occorre invece definire appositamente una nuova eccezione (per esempio chiamata BadDataException) per fronteggiare la possibilità che il formato dei dati in lettura sia errato, da lanciare eventualmente durante la lettura dei dati. Conviene che anche questa nuova eccezione sia controllata, perché il file potrebbe contenere dati corrotti per cause che sfuggono completamente al controllo del programmatore. In particolare, la si può definire come sottoclasse di IOException. Quindi anche questa eccezione deve essere gestita nel programma. Per quanto riguarda l azione di ripristino, essa può consistere in una nuova possibilità offerta all utente di fornire il nome del file, nel caso si verifichi uno degli errori previsti. Tale azione di ripristino non può che essere affidata alla parte del programma che interagisce direttamente con l utente, che si suppone sia il main. Il programma consiste di tre classi: DataSetReader, che fornisce gli strumenti per leggere da file scritti nel formato specificato e per lanciare le eventuali eccezioni, DataSetTester, che contiene il main, e BadDataException, che definisce la nuova eccezione controllata. // DataSetTester.java import java.io.filenotfoundexception; import java.io.ioexception; import java.util.scanner; public class DataSetTester public static void main (String[] args) Scanner in = new Scanner(System.in); DataSetReader r = new DataSetReader(); boolean done = false; while(!done) 10

try System.out.println( Digitare nome file: ); String fname = in.next(); // accetta nome file da leggere double data[] = r.readfile(fname); // legge dati da file double sum = 0; for (double d : data) sum = sum + d; System.out.println( La somma e : + sum); done = true; catch (FileNotFoundException e) System.out.println( File non trovato. ); catch (BadDataException e) System.out.println( Errore nei dati: + e.getmessage()); catch (IOException e) e.printstacktrace(); // fine ciclo while // fine main // fine classe DataSetTester Si noti come l accesso al file e la lettura dei dati vengano delegati al metodo readfile (e agli altri metodi) della classe DataSetReader, dai quali ci aspetta che possano essere sollevate le eccezioni: - FileNotFoundException: dopo la stampa di un messaggio di avvertimento, viene ridata all utente la possibilità di digitare il nome del file; - BadDataException: viene fornita una segnalazione dipendente in maniera più specifica dall errore verificatosi: - IOException: trattandosi di un qualunque altro errore di I/O, viene stampata la traccia delle chiamate di metodo, per consentire al programmatore un analisi più approfondita. L ordine in cui sono disposte le clausole catch è importante, data la relazione gerarchica esistente tra le classi di eccezioni. Se per esempio il blocco catch relativo a IOException precedesse quello relativo a FileNotFoundException, dato che quest ultima è anche una IOException, sarebbe proprio il blocco relativo a IOException a catturare anche la FileNotFoundException, qualora venisse lanciata, rendendo vano il tentativo di discriminare tra i diversi tipi di errore. //DataSetReader.java import java.io.filereader; import java.io.ioexception; import java.util.scanner; public class DataSetReader private double[] data; public double[] readfile(string fname) throws IOException FileReader r = new FileReader(fname); try Scanner in = new Scanner( r ); readdata(in); 11

finally r.close(); return data; // fine metodo readfile private void readdata(scanner in) throws BadDataException if(!in.hasnextint()) throw new BadDataException( Numero dati non corretto ); int numero = in.nextint(); data = new double[numero]; for(int i = 0; i < numero;i++) readvalue(in,i); if(in.hasnext()) throw new BadDataException( File non finito ); // fine readdata private void readvalue(scanner in, int i) throws BadDataException if(!in.hasnextdouble) throw new BadDataException( Dato double non presente ); data[i] = in.nextdouble(); // fine readvalue // fine classe DataSetReader // BadDataException.java import java.io.ioexception; public class BadDataException extends IOException public BadDataException() public BadDataException(String message) super(message); // fine classe BadDataException Si noti come alla BadDataException sia associato ogni volta un messaggio diverso, a seconda della tipologia di errore corrispondente al lancio dell eccezione, e come ciascuno dei metodi della classe DataSetReader si limiti a rilanciare l eccezione appropriata, senza tentare alcuna azione di recupero: l eccezione viene semplicemente trasferita al metodo chiamante. Inoltre, la presenza della clausola finally nel metodo readfile garantisce la chiusura del file anche se è stata lanciata una eccezione. Lo specificatore throws di questo metodo non include le classi FileNotFoundException e BadDataException, in quanto queste ultime sono sottoclassi di IOException. Riassumendo, e nell ipotesi che durante la lettura dei dati (metodo readvalue) si verifichi un errore, la sequenza degli avvenimenti è la seguente: a. Il main di DataSetTester chiama readfile di DataSetReader. b. readfile chiama readdata. c. readdata chiama readvalue. d. readvalue non trova il valore aspettato e lancia un eccezione BadDataException. e. readvalue non ha un gestore per tale eccezione e la rilancia, terminando immediatamente. f. readdata non ha un gestore per tale eccezione e la rilancia, terminando immediatamente. g. readfile non ha un gestore per tale eccezione e la rilancia, terminando immediatamente dopo aver eseguito la clausola finally che chiude il file. 12

h. Il main di DataSetTester ha un gestore per questa eccezione, che visualizza il messaggio all utente e gli dà una nuova possibilità (non vengono eseguite le istruzioni di elaborazione dei dati). 13

1. File e flussi La gestione di file e flussi in Java Un file o archivio è una collezione di dati persistenti. I dati memorizzati nelle variabili di un programma sono invece temporanei in quanto cessano di esistere al termine dell esecuzione del programma. I file sono degli oggetti fisici, normalmente memorizzati in una memoria di massa, che spesso trascendono la vita di un programma, ovvero esistono prima della sua esecuzione e continuano a esistere dopo la fine dell esecuzione. Sono quindi parte del sistema e per la loro gestione è normalmente adoperata una parte importante del sistema operativo, il file system, le cui funzioni sono rese disponibili ai programmi che devono manipolare le informazioni contenute nei file. I programmi, in qualunque linguaggio siano scritti, devono poter creare file, e leggere, modificare o cancellare file, eventualmente creati da altri programmi scritti in linguaggi diversi. Un file può contenere un documento scritto con un word processor, oppure un programma sorgente in linguaggio evoluto scritto con un editore di testi, oppure il codice oggetto generato da un compilatore C, oppure ancora i risultati delle elaborazioni effettuate da una applicazione scritta in Java sui dati contenuti in un database creato con un DBMS. E quindi evidente come tutti i linguaggi di programmazione debbano fornire il supporto per la creazione dei file e per la manipolazione del loro contenuto. Nei primi linguaggi di programmazione, questo supporto era normalmente costituito da istruzioni specifiche. La tendenza recente è invece quella di non definire delle primitive per la gestione dei file come parte del linguaggio. Per esempio, nel caso del linguaggio C il supporto per il trattamento dei file è disponibile attraverso la standard library. L implementazione delle funzioni di libreria (messe a disposizione dal sistema C) tiene conto del sistema operativo su cui il programma viene eseguito, agevolando l invocazione corretta delle funzioni del sistema operativo stesso. Questo consente al programmatore di trattare i file senza doversi preoccupare dei dettagli della gestione realizzata dal file system. Analogamente, nel caso del linguaggio Java il package java.io, che fa parte di Java API, contiene le definizioni delle classi utilizzabili per la gestione dei file (o meglio, dei flussi, come si vedrà tra breve). I dati contenuti in un file sono ovviamente combinazioni di bit. Questa visione di basso livello dei dati è particolarmente scomoda sia per il programmatore sia per gli utilizzatori di un programma. L uno e gli altri sono infatti abituati a rappresentare l informazione in termini di nomi, date, numeri, parole, etc. che assumono un significato nel contesto dell applicazione. Per esempio, un programma che debba elaborare delle statistiche sugli esiti di un esame degli studenti di una classe, si baserà su una struttura logica dei dati che probabilmente prevedrà una indicazione delle informazioni necessarie, come cognome, nome e voto, ripetuta per ciascuno degli studenti. Ci sarà quindi un record per ogni studente, costituito per esempio dai seguenti campi: 1. Numero di matricola 2. Cognome 3. Nome 4. Votazione conseguita 14