SQLException rilanciate da sottoclassi di Model ed eccezioni lanciate in generale

[Roberto Baldin]

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 GestoreStazioneTerra o comunque uno dei primi metodi a partire, eventualmente il main stesso.
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).

[Alessandro Bruni (alessandro-bruni)]

Ho risolto adottando la prima delle due soluzioni: viene rilanciata una runtimeexception con il printstacktrace dell'eccezione originaria.
Mi pare un buon compromesso.