Gestire apertura file con eventuale exception

[andbin]

Che consiglio mi daresti? Come dovrei procedere?

Il fatto di aver creato una classe a parte (ApriFileIrraggiamento) solo per la gestione del file, ok, è buono.

Se Irraggiamento rappresenta tutto il file (e mi pare di capire che è così), allora il fatto che parseString riceva il BufferedReader, tutto sommato potrebbe anche andare bene, perché tutta la gestione è in apriFiles e quindi per forza glielo deve passare.
Ma se ci pensi, e ragioni, parseString legge solo una riga e fa il parsing di quella riga. Quindi NON è affatto necessario che parseString riceva il BufferedReader. Basta che riceva la stringa.
Il parseString viene chiamato 4 volte da apriFiles e tu per evitare 4 readLine(), per questo hai passato il BufferedReader. Ma potevi fare es.

String latitude = parseString(b.readLine(), "Lat", "Lati", true);
......

Che costava molto poco ....

Quello che va meno bene è che in parseString catturi IOException, fai un log (e questo va bene) ma poi finisce lì. No, quel IOException dovrebbe poter uscire da parseString e anche da apriFiles.


Ah, qui ad esempio:

String[] intestazione = b.readLine().split("\\s+"); // intestazione

non è molto buono: se readLine() restituisce null, ti becchi NullPointerException. Ma se ti dà null, vuol dire che sei a fine file e se quella riga te la aspettavi, vuol dire che il file è "malformato" e lo devi segnalare opportunamente.
Dovresti valutare questo aspetto in generale, anche per le altre readLine()

[roquentin]

Il fatto di aver creato una classe a parte (ApriFileIrraggiamento) solo per la gestione del file, ok, è buono.

Se Irraggiamento rappresenta tutto il file (e mi pare di capire che è così), allora il fatto che parseString riceva il BufferedReader, tutto sommato potrebbe anche andare bene, perché tutta la gestione è in apriFiles e quindi per forza glielo deve passare.
Ma se ci pensi, e ragioni, parseString legge solo una riga e fa il parsing di quella riga. Quindi NON è affatto necessario che parseString riceva il BufferedReader. Basta che riceva la stringa.
Il parseString viene chiamato 4 volte da apriFiles e tu per evitare 4 readLine(), per questo hai passato il BufferedReader. Ma potevi fare es.

String latitude = parseString(b.readLine(), "Lat", "Lati", true);
......

Che costava molto poco ....

In effetti hai pienamente ragione ed ho fatto così:

private String parseString(final String input, final String name1, final String name2, final boolean skipLast) {
        
        if (input != null && !input.trim().isEmpty() && (input.startsWith(name1) || input.startsWith(name2))) {
            int index = input.indexOf(":");
            if (skipLast) {
                int indexV = input.indexOf(",");
                return input.substring(index + 1, indexV);
            } else {
                return input.substring(index + 1);
            }
        }
        return null;
    }

Quello che va meno bene è che in parseString catturi IOException, fai un log (e questo va bene) ma poi finisce lì. No, quel IOException dovrebbe poter uscire da parseString e anche da apriFiles.

Passando non il buffereader ma la singola stringa a ParseString, mi segnalava errore sulla catch cause

exception IOException is never thrown in body of corresponding try statement

Ah, qui ad esempio:

String[] intestazione = b.readLine().split("\\s+"); // intestazione

non è molto buono: se readLine() restituisce null, ti becchi NullPointerException. Ma se ti dà null, vuol dire che sei a fine file e se quella riga te la aspettavi, vuol dire che il file è "malformato" e lo devi segnalare opportunamente.
Dovresti valutare questo aspetto in generale, anche per le altre readLine()

Infatti ho notato che se mi restituisce null, ho NullPointerException se non trova quella riga ma non capisco cosa vuoi dire con

e se quella riga te la aspettavi, vuol dire che il file è "malformato" e lo devi segnalare opportunamente.

[andbin]

Passando non il buffereader ma la singola stringa a ParseString, mi segnalava errore sulla catch cause

Se parseString non riceve più BufferedReader, allora chiaramente non serve più nemmeno il try-catch, visto che nulla lì dentro potrebbe lanciare IOException

Infatti ho notato che se mi restituisce null, ho NullPointerException se non trova quella riga ma non capisco cosa vuoi dire con

Se arrivi a quel punto e quella riga ti aspetti che ci sia sempre (non è opzionale) .... e invece non c'è (perché sei a end-of-file), vuol dire che il file è malformato. Dovresti segnalarlo con una eccezione.
E in generale, dovresti fare questi ragionamenti per ogni riga che è da ritenersi fondamentale per il formato del file.

[roquentin]

Se arrivi a quel punto e quella riga ti aspetti che ci sia sempre (non è opzionale) .... e invece non c'è (perché sei a end-of-file), vuol dire che il file è malformato. Dovresti segnalarlo con una eccezione.
E in generale, dovresti fare questi ragionamenti per ogni riga che è da ritenersi fondamentale per il formato del file.

Infatti è proprio questo il punto..come faccio a segnalare con l'eccezione ed indicare all'utente che il file non è nel formato previsto (è completamente vuoto o manca quella detterminata stringa in quella determinata posizione) ????

[andbin]

come faccio a segnalare con l'eccezione ed indicare all'utente che il file non è nel formato previsto

Hai già fatto una tua DatiMeseInvalidiException .... se ti va bene che sia usata anche per casi come questo .... quale è il dubbio?

[roquentin]

Hai già fatto una tua DatiMeseInvalidiException .... se ti va bene che sia usata anche per casi come questo .... quale è il dubbio?

Ok, si. Ma io vorrei che fosse comunicato all'utente con un messaggio su JOptionPane...

[andbin]

Ma io vorrei che fosse comunicato all'utente con un messaggio su JOptionPane...

Quello è un altro discorso, sarà da fare altrove (non certo nella ApriFileIrraggiamento!).