- Il codice è tutto ammassato, non ci sono righe vuote che separano le varie operazioni. Ad esempio, hai codice di controllo e operazioni vere e proprie troppo amalgamate. Questo rende difficile capire a colpo d'occhio cosa stai facendo
- Usi variabili inutili, ad esempio per la query: passa direttamente al prepareStatement, no?
Sì, sono talebano su 'ste cose
Non c'è il finally: in caso di eccezione lo statement resta aperto, andando a occupare inutilmente risorse.
Il problema più grave IMHO è che in caso di eccezione stai facendo <i>troppo</i>: insertMenu dovrebbe fare una query, e basta. Te gli stai dando la responsabilità di avvisare l'utente che qualcosa è andato storto. Questa gestione andarebbe fatta a livello più alto: cosa succede se insertMenu facesse parte di una libreria che distribuisci ad altri sviluppatori? Potrebbe essere usata in un contesto in cui l'interfaccia grafica neanche esiste (pensa ad un batch notturno che legge dei dati da file e inserisce tutto a db, senza l'intervento dell'operatore). insertMenu() dovrebbe limitarsi a lanciare l'eccezione: sarà chi lo chiama a decidere cosa fare: avverto l'utente? Scrivo in un file di log? Mando una email al responsabile?
Spero di essere stato chiaro ^^
Io avrei fatto una cosa del genere, delegando la gestione a chi chiama il metodo:
codice:public static void insertMenu(String field) throws SQLException, IllegalArgumentException { PreparedStatement statement = null; try { if (field == null || field.isEmpty()) { throw new IllegalArgumentException("Please provide a not-null and not-empty value for 'field'"); } statement = connection.prepareStatement("INSERT INTO Menu VALUES (NULL, ?)"); statement.setString(1, field); statement.executeUpdate(); } finally { if (statement != null) { statement.close(); } } }
Sarebbe un problema se venisse riassegnato visto che in genere un auto_increment è usato (purtroppo) come primary key...
Ah, anche il fatto che sia static non mi piace ma bisognerebbe vedere un attimo come hai organizzato l'architettura dell'applicazione.
SpringSource Certified Spring Professional | Pivotal Certified Enterprise Integration Specialist
Di questo libro e degli altri (blog personale di recensioni libri) | NO M.P. TECNICI
I computer sono incredibilmente veloci, accurati e stupidi.
Gli uomini sono incredibilmente lenti, inaccurati e intelligenti.
Insieme sono una potenza che supera l'immaginazione.
A.Einstein
Ok, ho messo un po' di spazi e di commenti in più e tolto la stringa inutile
Ok, però questo è solo un progetto per un esame, non è un vero software che dovrò distribuire a qualcuno. Non è previsto che debba funzionare senza interfaccia grafica perciò non mi sono preoccupata di questi dettagli. Le tue critiche mi sembrano più che sensate ma credo che nel contesto in cui sono attualmente posso evitarmi queste complicazioni. Del resto nel corso che abbiamo fatto nessuno ci ha spiegato veramente come mettere in piedi un'applicazione complessa.
Ammetto che la gestione delle eccezioni è ancora un po' oscura per me, infatti mi limito a prendere spunto da esempi già fatti. Ho capito il concetto a grandi linee ma non conosco tutte le sottigliezze.
perché purtroppo?
perché non dovrebbe essere static? sinceramente su questa cosa non ci ho riflettuto molto mi sono limitata a modificare la classe che ci aveva fornito il prof a suo tempo per connettersi a un database e i metodi erano tutti statici, così gli altri che ho inserito (inserimento dati e creazione db e tabelle) li ho fatti uguale...
grazie per i tuoi consigli!