SQLException rilanciate da sottoclassi di Model ed eccezioni lanciate in generale
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Automatic Explorer |
Fix Committed
|
Medium
|
Alessandro Bruni |
Bug Description
Le sottoclassi di Model lanciano un'eccezione controllata SQLException che dev'essere obbligatoriamente gestita dai metodi che richiamano quelli di tale classe, nella fattispecie aggiorna() di View.
Trovo che questa non sia la soluzione migliore, perchè costringe chi implementa View a gestire tale eccezione. Non si può rilanciare perchè l'interfaccia di View non ha dichiarazioni di throws... e aggiungerla sarebbe concettualmente scorretto.
Soluzioni proposte:
1 - Controllare la SQLException in Model e rilanciare una nuova eccezione sottoclasse di RuntimeException, quindi non controllata. Mi sembra corretto, visto che il fatto che il database esista o sia accessibile è evidentemente un problema a Runtime e gestire tale eccezione nei Widget non ha senso.
2 - non è un'alternativa a uno, anzi sarebbe meglio sommare entrambe le soluzioni. Questa seconda proposta comunque consiste nel controllare le eccezioni (gravi intendo, non BufferPieno!) al posto giusto, che dovrebbe essere GestoreStazione
In questo modo anche per le gestioni impossibili da gestire, per esempio appunto la mancanza di connessione al db, si potrebbero semplicemente visualizzare dei popup di errore irreversibile (piuttosto che visualizzarlo a riga di comando).
Changed in automaticexplorer: | |
importance: | Undecided → Medium |
status: | New → Confirmed |
Ho risolto adottando la prima delle due soluzioni: viene rilanciata una runtimeexception con il printstacktrace dell'eccezione originaria.
Mi pare un buon compromesso.