Gestire apertura file con eventuale exception

[andbin]

Perchè nella classe di una eccezione non va mai fatta alcuna interazione con l'utente ?

Perché una eccezione è solamente un semplice oggetto che viene istanziato, lanciato e poi catturato altrove, potenzialmente anche molto più a monte di dove è stata scatenata la eccezione. Non è la classe della eccezione che deve interagire con l'utente!

Una eccezione può eventualmente contenere informazioni extra, pertinenti al motivo della eccezione. Prendi come esempio una ipotetica ConfigurationKeyNotFoundException, una informazione extra potrebbe essere appunto la 'key' che non è stata trovata. Quindi potrebbe essere una cosa tipo:

public class ConfigurationKeyNotFoundException extends Exception {
    private String key;

    public ConfigurationKeyNotFoundException(String key) {
        super(String.format("Configuration key '%s' not found", key));
        this.key = key;
    }

    public String getKey() {
        return key;
    }
}

Questo va bene, è assolutamente appropriato.

Ma le eccezioni, in generale:
- Non devono essere usate solo per "passare" informazioni da un punto ad un altro (più a monte) giusto solo perché farebbe comodo (sarebbe un abuso e non è quello l'obiettivo delle eccezioni).
- Non devono fare I/O in generale, a meno che sia pertinente alla eccezione, ad esempio per "localizzare" il messaggio.
- Non devono interagire con l'utente in alcun modo, meno che mai con delle message-box grafiche.


Se la eccezione è "importante" e oltretutto checked, dovrà essere catturata e gestita prima o poi da qualche parte a monte, e se dove gestisci la eccezione c'è una nozione chiara del contesto e di come deve avvenire l'interazione con l'utente, allora lì sì, puoi aprire una message-box di errore.

Già ... il problema è appunto tenere ben separati i concetti. Quel tuo metodo 'parseString' dove è messo? Visto che hai un file da gestire e con un formato ben preciso, mi aspetterei che tu abbia fatto una classe a sé stante che si occupa solo della lettura/parsing del file. Hai fatto così? O hai fatto un bel miscuglio di concetti in una unica classe?

Ho pensato di eliminare

throw new DatiMeseInvalidiException("Identificatore non presente");

inserendo un controllo sul valore di ritorno della classe

che ne dici?

Non, è peggio! Innanzitutto un 'null' molte volte è ambiguo e perlomeno dovresti documentare (senza che qualcuno debba per forza guardarsi il tuo codice e capire la logica) cosa significa un null restituito da parseString. Poi comunque la possibilità di un null, forza il chiamante a fare almeno un test, quindi ... più codice.
Inoltre null è solo uno, non hai altri valori speciali, quindi se ci sono diverse problematiche da segnalare, usare sempre e solo "null" è ovviamente molto restrittivo.

E infine, il fatto che a parseString passi un BufferedReader, dà abbastanza (a me perlomeno) l'idea che stai ragionando poco "ad oggetti".


E tutto questo che stai dicendo è quasi certamente un segno delle tue parole dei giorni scorsi: "Purtroppo non riesco ancora ad entrare nella logica del linguaggio ad oggetti...ma ci riuscirò"