ciao,
fermat ha scritto:
per quanto riguarda i try/catch ho ripreso un abitudine che mi avevano consigliato, e cioè di far uscire fuori l'eventuale errore nella parte grafica.
Effettivamente, se l'errore non può essere ignorato è giusto che l'eccezione arrivi all'interfaccia grafica in modo che l'utente ne sia informato. Tuttavia, secondo me, il messaggio nudo e crudo di una MySqlException non dà alcuna informazione all'utente, o meglio, magari riesce a capire che manca la connessione al DB ma all'atto pratico non gli fornisce aiuto su come risolvere la cosa.
La MySqlException dovrebbe essere catturata nel punto in cui ti colleghi al db, loggata in qualche modo (es. event log) e poi rilanciata in qualcosa che possa essere più fruibile da un utente.
try { ... }
catch (MySqlException ex)
{
//qui logghi l'eccezione nell'event log
//poi rilanci una tua eccezione incapsulando quella originale
throw new Exception("Impossibile collegarsi al database. Assicurati di essere collegato alla rete o contatta l'amministratore per assistenza.", ex);
}
Nel caso l'interfaccia grafica, per qualche motivo, volesse risalire all'eccezione originale può pur sempre accedere alla proprietà .
InnerException.
try{
dataGridViewEntrate.DataSource = db.getEntrate();
} catch (Exception ex) {
MessageBox.Show(ex.Message);
//ex.InnerException è la MySqlException originale
}
Così hai anche il vantaggio di isolare meglio l'interfaccia grafica dallo strato di accesso ai dati. Lì infatti non vedi più alcun riferimento a MySqlException e questo ti rende libero, in futuro, di passare a MySql a Sql Server senza per questo dover revisionare tutto il codice alla ricerca di occorrenze da sostituire.
ciao.