Gestione delle eccezioni di runtime durante la lettura da file

Non c'è una risposta semplice. Mettiti nei panni dell'utente e pensa a cosa si aspetterebbe se ci fosse un file di dati che è corrotto nel mezzo.

Diciamo che ho una rubrica con 1200 indirizzi e ce n'è una che il tuo codice non può leggere. Come utente, mi aspetto di vedere 1199 indirizzi. Mi aspetto addirittura un messaggio di errore? Io non la penso così O al massimo una volta. Perché se uso un'applicazione e ogni volta che cerco un indirizzo ottengo un messaggio di errore sanguinolento che sarò notevolmente incazzato.

Supponiamo che la mia applicazione abbia appena ricevuto un file con dati finanziari. Fornisci informazioni su 217 fatture che la mia azienda deve pagare e una che il tuo codice non può leggere. Come utente, mi aspetto che venga detto che questo file è corrotto, così posso tornare alle persone che inviano il file e ottenerne uno nuovo. Ignorare un disegno di legge che è stato corrotto sarebbe molto, molto brutto e potrebbe portare a conseguenze disastrose.

Quindi vedi: dipende. Guarda la situazione e fai qualsiasi cosa abbia senso. Non farlo in termini di sviluppatore di software, ma dal punto di vista dell'utente finale che ha bisogno dei risultati più utili.

Se ti aspetti dati sporchi:

I dati sporchi sono quando alcuni dei record possono essere sporchi o non corretti. La qualità dei dati potrebbe non essere elevata. In questo caso, basta inserire i record non validi in un file di salto, registrarlo e proseguire fino al successivo. Al termine dell'elaborazione, crea una notifica con un riepilogo dei risultati e prendi nota del percorso del file di salto.

In questo modo è possibile elaborare la maggior parte dei record e annotare quelli sporchi per ulteriori rimedi.

Se ti aspetti dati puliti:

Pulisci dati significa che ogni record è valido. Se i dati non sono puliti, interrompere l'elaborazione e creare un avviso. Questo scenario richiede una pre-schermata (primo passaggio) di ogni record nel file per determinare se è valido o meno. Se i record sono tutti validi, il file è valido e può essere elaborato. Se il file non è valido, molto probabilmente l'intero file viene scartato e chiunque / qualunque cosa sta generando il file dovrà crearne uno nuovo da elaborare.

A seconda delle esigenze, entrambe le opzioni sono accettabili.

Ovviamente ciò dipende dall'implementazione e dal grado di complessità del tuo sistema. Ma in generale, sceglierei di creare qualcosa come FileParsingException e ObjectBuildingException .

Quindi probabilmente creerai una classe ObjectReader che analizza il file e crea l'oggetto (potenzialmente delegato a FileParser e una classe ObjectBuilder ), intercetta queste eccezioni e crea l'eccezione corretta.

Quindi puoi cogliere l'eccezione ad un certo punto nello stack in cui puoi dare il feedback dell'utente appropriato e magari dare l'opzione di selezionare un altro file o whatnot.

La cosa buona è che puoi aggiungere informazioni rilevanti su cosa è andato storto senza imporre complessità all'utente della classe.

Ad esempio, potresti non volere che la classe client sappia che il file deve contenere int s perché ciò richiederebbe l'implementazione di una logica che si interromperà quando la classe del lettore cambierà. Se ci sono molti clienti, questo diventa un inferno molto rapidamente. (questo probabilmente ha più senso quando l'analisi è più complicata).