Newsgroup: it.comp.java
Titolo: Gestione Delle Eccezioni

Ho creato un metodo che passa una stringa in ingresso e genera un eccezione 
se questa stringa non viene trovata in un array di stringhe, fino a qui più 
o meno semplice. Il mio problema è:
si può gestire l'eccezione in modo "ricorsivo"? Nel senso che se la stringa 
non viene trovata, e quindi viene lanciata l'eccezione, io posso inserire 
una stringa nuova e vedere se questa esiste? tnx 

Ciccio Pasticcio wrote:

E' un problema implementativo, di soluzioni ne puoi trovare a migliaia.
Ad esempio: metti la chiamata all'interno di un ciclo, catturi 
l'eccezione e nella catch non fai assolutamente nulla, mentre nella try 
immediatamente dopo la chiamata della funzione ci metti un bel break;.



Tieni presente che le eccezioni NON devono essere usate come pseudo valori
di riotrno, ma solo per segnalare eventi rari, inattesi, non previsti.
Nel tuo caso il metodo dovrebbe ritornare un eccezione solo se il caso
normale e atteso è che la stringa venga trovata nell'array. 
ciao domenico

 di riotrno, ma solo per segnalare eventi rari, inattesi, non previsti.
   Beh, dai, non proprio. Nel layer di persistenza del framework che uso e'
perfettamente normale una cosa del tipo:
DBObject dbo = new DBObject();
dbo.setField("chiave", valore)
try {
    dbo.retrieve();
    //Caso trovato
} catch (DBRecordNotFoundException meow) {
    //Caso non trovato
}
che non mi pare ne' inefficiente ne' illeggibile...



Illegibile no. Inefficente sě, sicuramente.
ciao domenico

 normale e atteso è che la stringa venga trovata nell'array.
Non concordo. Esempio classico: controllo di numericità nel parsing di
una stringa (che arriva da une getString di una tabella oppure da un
JTextField).
try{
int eta = Integer.parseInt(stringa);
}
catch(NumberFormatException n){
System.out.println("Il valore inserito non è numerico")
}

> Illegibile no. Inefficente sì, sicuramente.
   Perche'?
-- 
---
Francesco Galli / Cinghiale Mannaro
Personal: 
http://cinghialemannaro.splinder.com
TMS project: 
http://tms.inera.it

 o meno semplice.
int isStringInArray(String src, String[] array)
// returns array index of src in array
// -1 in src not in array
ciao domenico

    Perche'?
Scusa per prima, ero di fretta. Mi dilungo un po di più ora.
La gestione delle eccezioni, per tutte le JVm, è costosa, perché comporta
la creazione dello stacktrace al runtime: 
http://www-106.ibm.com/developerworks/java/library/j-perf07303.html
Nel tuo caso sicuramente il tempo per la gestione delle eccezioni è
trascurabile rispetto ai tempi del DB (anche se prob. la cosa poteva in
ogni caso essere gestita in maniera più efficente dal framework, daltronde
un'istruzione SQL può uscire con successo ritornando 0 righe)
Invece nel caso del primo post (cercare una stringa in un array di
stringhe) l'eccezione mi sembra inutile a meno che l'evento non sia raro,
inatteso, sintomo di un errore.
ciao domenico

 condizione di errore se non con un'eccezione.
Appunto, quindi NON sempre è vero che (cito) "le eccezioni NON devono
essere usate come pseudo valori di ritorno, ma solo per segnalare


 inatteso, sintomo di un errore.
    Se uno si aspetta di trovarla il 90% dei casi effettivamente l'uso
dell'eccezione e' esagerato. Andrebbe bene solo se i motivi per cui quel
metodo ritorna una pernacchia possono essere multiformi. Sull'esempio della
domanda concordo con te, sulla generalizzazione invece no :)


 eventi rari, inattesi, non previsti"
Ri-ribadisco quanto da te citato: è sempre vero. E di esempi ne potremmo
fare tanti. Cosa restituisce una map se si ga una get di un valore non
esistente? e una hashtable? un'eccezione o un valore NULL? 
ciao domenico

 domanda concordo con te, sulla generalizzazione invece no :)
Diciamo che la mia prima osservazione era del tipo:
Non usate le eccezioni come metodi di controllo del flusso, ma solo per
segnalare errori o comportamenti anomali, aldifuori del normale flusso del
codice.
ciao domenico