Perché non posso creare una classe per un Try compreso ciò che provo e poi eseguirlo nel blocco try {} ? Perché non è pratico?
class DBConnectTry extends Try {
TryResponse response[] attempt(TryObject o[]...){
//try to connect to database
}
}
Quindi in try ... catch potrei invocare solo DBConnectTry.attempt . Migliorerebbe la leggibilità / chiarezza / modularizzazione o non è una buona idea?
Direi che non è una buona idea. Questo tipo di incapsulamento non è una pratica standard per le eccezioni, perché le eccezioni dovrebbero essere ... eccezionalmente rare per cominciare. Il codice di questa varietà sembra buono sulla carta, ma in pratica sarà un incubo da mantenere. Scrivi solo un numero sufficiente di codice per risolvere il problema. Vedi il principio KISS e non ripeterti .
Il codice ridondante non aiuta la chiarezza o la leggibilità del codice, e l'aggiunta di classi e metodi aggiuntivi per attività di piccole dimensioni renderà solo gonfia l'origine della tua applicazione.
Inoltre, considera che sarà più difficile rimuovere tali classi in un secondo momento (se necessario) piuttosto che implementarle in primo luogo.
Considera l'utilizzo della parola chiave throws per propagare le eccezioni a una classe chiamante e quindi gestirle lì. Invece di un'interfaccia Prova, con l'implementazione della classe DBConnectTry, crea un metodo nella classe di connessione del database impl che ha un blocco catch try per ciascuna connessione.
public class DBConnectionManager{
public Connection getConnection() throws SQLException {
Connection conn = null;
conn = //Get connection obj from DriverManager or whatever
return conn;
}
}
Ogni chiamata a DBConnectionManager # getConnection dovrebbe gestire SQLExceptions o passarle alla successiva classe di chiamata.
Inoltre, esamina i framework di registrazione come log4j e slf4j. Non hai bisogno di una classe per incapsulare messaggi di eccezione (la tua classe TryResponse). È possibile inserire più messaggi in semplici matrici / elenchi di oggetti String.
Leggi altre domande sui tag encapsulation java object-oriented-design exceptions