Newsgroup: it.lavoro.informatica
Titolo: [OT] try & catch

		try 
			{
				//fa qualcosa....
			}
			catch ( Exception ex)
			{
				throw ex;
			}
Non capisco che senso ha questa gestione degli errori!!! nella catch
non fa nulla che rigenerare l'eccezione.
_Ma non bastava non gestirla?_ 
Ultimamente trovo questo codice ovunque... Poteva andare bene se
scriveva un log (anche se con .NET č quasi inutile in quanto l'errore
ha gią un trace) ma non lo fa!!!!
chi ha scritto il codice non capisce nulla o io non ho capito nulla?

 chi ha scritto il codice non capisce nulla o io non ho capito nulla?
sono d'accordo con te. anche secondo me č inutile. ammeno che non voleva
che l'eccezione venga lanciata in una specifica riga del codice, ma poco
probabile.

 chi ha scritto il codice non capisce nulla o io non ho capito nulla?
Gara difficile ;-)  Scherzo ovviamente, un try catch così è solo
deleterio, hai ragione tu.

 No, non la rigenera, semplicemente la passa al chiamante
Sai che non lo so? O meglio, credo dipenda da eventuali ottimizzazioni
del compilatore; compilatore che, se fosse beota, dovrebbe aggiungere
sia la routine per la gestione dell'errore che la routine di
generazione di un nuovo errore.
-- 
Ciao!
Luca

 chi ha scritto il codice non capisce nulla o io non ho capito nulla?
Se tu non hai capito nulla, sappi che sei in - buona - compagnia perché
ci sono anch'io.
-- 
Ciao!
Luca

 chi ha scritto il codice non capisce nulla o io non ho capito nulla?
Te la spiego io: è l'eredità lasciata su un povero programmatore da
un linguaggio (del quale mi astengo dal pronunciare anche il nome) nel
quale se non rilanci espressamente le eccezioni queste non vengono
propagate al chiamante ma si perdono irrimediabilmente ;)
bye!

 _Ma non bastava non gestirla?_ 
[cut]
Si, bastava non gestirla.
Considera anche questo scenario: il programmatore dice "ah, se qui c'è 
una eccezione la voglio loggare". Poi però si dimentica (o meglio, se ne 
frega) di scrivere tutta la parte di logging e l'eccezione rimane lì 
appesa.
Ciao,
Giulio

 Ultimamente trovo questo codice ovunque...
Odio l'eccessivo uso di try...catch. Programmazione totalmente difensiva. :( 
-- 
__________________________________________________
Luc (33, CO)
MS Visual Studio developer - Programmer since 1985
__________________________________________________


Credo che l'idea fosse quella di lanciare un'eccezione diversa da
quella generata (di solito le segnature dei metodi non riportano
generiche eccezioni Exception).
Purtroppo molti usano erroneamente le eccezioni anche come strutture di
controllo.
Esempio, invece di usare:
if (x!=null) print(x.toString()) else print ("x is null")
usano:
try { print(x.toString()) } catch (NullPointerException ex) {print ("x
is null")}
ciao, U.

 Odio l'eccessivo uso di try...catch. Programmazione totalmente difensiva. :(
This is Java.

 Non capisco che senso ha questa gestione degli errori!!!
cosi' come è scritto a nulla.
pero' se voleva rigenerare una eccezzione con un throw new exception
per cambiarne il messaggio, oppure lanciare una eccezzione custom, fare
uno switch sul tipo di eccezzione, oppure settare variabili, oppure
come dici usare un log avrebbe avuto senso.
ma non vedo neppure quale sia il grande problema.

 ha già un trace) ma non lo fa!!!!
Se non parli con l'autore non saprà mai perchè l'ha fatto.
Posso solo fare un ipotesi: il tizio doveva fare il debug su una
eccezione e ha lasciato sporcizia a giro.

 is null")}
Yeah, non tanto frequente come il precedente, ma ogni tanto si legge
(fortunatamente non con il team con cui lavoro ora :))).
-- 
ale
http://www.riolo.org

 eccezione e ha lasciato sporcizia a giro.
Risposta che ricevo praticamente il 100% delle volte che chiedo per
quale motivo qualcuno ha scritto un codice simile a quello (o che
magari invece di rilanciare dichiara e definisce una"int i = 0;").
-- 
ale
www.riolo.org

 chi ha scritto il codice non capisce nulla o io non ho capito nulla?
Magari semplicemente è un modo personale del programmatore originario 
per ricordarsi che lì c'è una eccezione che dovrà essere gestita in un 
secondo momento, non pensando che nel frattempo magari il codice 
sarebbe passato in mano ad altri...
Ciao,
Alessio (a.k.a. Kinglion Il Meticcio)
-- 
11:15, restate my assumptions: 1. Mathematics is the language of 
nature. 2. Everything around us can be represented and understood 
through numbers. 3. If you graph these numbers, patterns emerge. 
Therefore: There are patterns everywhere in nature.
(Maximilian Cohen, Pi)

 _Ma non bastava non gestirla?_ 
Ipotesi:
- se il chiamante non la gestisce, l'eccezione viene loggata come
proveniente da questo codice, e non da chi l'ha generata realmente.
- il programmatore voleva ricordarsi che li' c'era qualche eccezione da
gestire, ma poi non ha potuto/voluto perfezionare il codice.
- un validatore di codice solleva un warning per ogni sezione di codice
che puo' generare una eccezione non gestita. Questo codice lo "silenzia".
- il programmatore viene pagato per linee di codice prodotte al giorno.
Ciao,
 ___ 
/_|_\  Umberto Salsi
\/_\/  
www.icosaedro.it

 is null")}
Caspita che fantasia! :-|
Ciao
Mirko

Tra una pausa e l'altra nell'organizzazione del ns master
rieccomi a leggere gli interessanti post di questo NG  : )
Come state?
Secondo me il problema e' che non hai indicato il cuore
di tutta la faccenda. Ovverosia il finally. Senza finally quella
struttura e' ridondante. Se la vedi invece nell'ambito della sintassi
completa, ti rendi conto che e'  *assolutamente* necessaria.
Ci sono almeno un miliardo di situazioni in cui hai necessita' di far
compiere determinate operazioni in uscita da una fun o sub in cui
si sia verificata un'eccezione. Esempio: chiudere uno streamwriter
aperto,
chiudere una connessione aperta, resettare un flag di semaforo, etc...
Cio' fatto naturalmente hai necessita' di lasciare "bubbling up"
l'eccezione senza distruggerne lo stack, e a quello serve il throw
senza argomenti...
T

 chiudere una connessione aperta, resettare un flag di semaforo, etc...
Volendo in C# esiste anche il concetto di Disposable per questo scopo. 
Cioè delegare per il rilascio delle risorse l'oggetto che le usa.

 generazione di un nuovo errore.
Per quanto ne so l'eccezione viene comunque generata, anche senza try
catch, quindi fatta risalire nello stack della chiamate fino a un
chiamante marcato  per la gestione errori.
Il costrutto catch dovrebbe quindi ricevere per riferimento
l'eccezzione ed il throw ridare il controllo al gestore errori...  o
almeno immagino perchè non so come lavora internamente.
Comunque mi ricordo che il throw dell'errore (almeno nella 1.1) era
indicato come una operazione molto costosa... per cui era
sconsigliatissimo fare catch solo per scrivere un messaggio e poi
"passare ad altri", i try catch inutili o quasi vanno evitati.
Dal compilatore c'è da aspettarsi di tutto, anche che non compili
affatto il codice considerandolo inutile....  basterebbe guardare con
un decompilatore la DLL risultante : o anche no dici al programmatore
di scrivere solo le righe che servono cosi fa prima e meglio ;)

 Cioè delegare per il rilascio delle risorse l'oggetto che le usa.
si', con using, ma non sempre riesci a farci tutto. try ...catch
...finally riesce
ad essere piu generale, secondo me. Ci sono situazioni che col primo
non gestisci
ma col secondo si'...
T

 per fare clean up locale senza svuotare lo stack delle eccezioni.
Ripeto: finally NON richiede che tu gestisca l'eccezione, per cui il 
blocco catch che semplicemente rilancia l'eccezione continua ad essere 
ridondante.

 sia portare argomenti solidi di verifica. 
http://msdn2.microsoft.com/it-it/library/zwc8s4fz(VS.80).aspx
In Java è una tipica domanda dell'esame di certificazione.

 ridondante.
Andando comunque al punto, credo che e' utile mettere il catch quando
vi sono dei cleanup
diversi in caso di eccezione rispetto alla corretta terminazione. Per
esempio se il cleanup e' una funzione che chiude uno streamwriter (sw)
ed ha anche un argomento booleano per indicare la visualizzazione del
file, allora potremmo avere:
       Dim s As String
        Try
           '...
           Termina_ApriFile(sw, True)
        Catch ex As Exception
          if sw isnot nothing then
             Termina_ApriFile(sw, False)
          end if
          Throw
        Finally
            ' ... altri eventuali clean up
        End Try
in questo caso abbiamo la necessita di rilanciare l'eccezione
senza svuotare lo stack.

 ha scritto:
<CUT>
Sergio Leone
C'era una volta il West
scena made:
Jiill fa il caffe
Cheienne lo beve
Jill ama entrambi, Cheienne e Armonica, soprattutto Armonica
Cheienne dice :
"Arrivera' , berra' il caffe', pigliera' il cappello e se ne andra', perche'
puzza di morto"
"Io resterei ma non posso"
Arriva Armonica. Prende il cappello e se ne va.
Cheyenne finisce il caffe' e se ne va anche lui
passa il fiume e ha un proiettile nello stomaco , senza averlo detto a Jill,
e muore.
catchare una Exception generica non subclassata e' la stessa cosa.
in particolare hai catchato anche una Null Pointer , vivi lo stesso , ma sei
gia' morto, il tuo programma e' morto ma sopravvive
Per poesia e amore lo potresti fare con Jill
ma non puoi portarti una null pointer catchata in un programma perche' Jill
non c'e'
scusate la sofisticatezza, ma non catchate mai una Exception non
subclalssata perche' il programma andra' avanti, e' morto e ha un proietile
dentro, anche se sta in piedi fino al fiume
Jill e' bella comunque :-)
Nicola
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 diversi in caso di eccezione rispetto alla corretta terminazione.
Andando *esattamente* al punto, direi che è utile mettere il catch
quando serve :-) ovvero quando si intende "trappare" per gestire
l'eccezione. Il cleanup, inteso come quelle operazioni che devono
essere eseguite sempre e comunque indipendentemente da come si sta
uscendo dal metodo (eccezione o no), è delegato al finally che viene
eseguito *indipendentemente* dai catch.
Così è, se vi pare (e anche se non vi pare) :-)

 eseguito *indipendentemente* dai catch.
agreed ;-))

E ci voleva tanto ? Ho letto un'abbondante dozzina di reply prima di
arrivare a questa.
In pratica, quoto.
Ciao.
Paolo.
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 chi ha scritto il codice non capisce nulla o io non ho capito nulla?
Non e' possibile che sia codice generato automaticamente, ed
erroneamente lasciato cosi' solo per "incuria"?

 arrivare a questa.
Notare che quella definizione (giusta) sta nel tutorial di qualsiasi
linguaggio di programmazione con un costrutto simile per la gestione
delle eccezioni :-)
Mi meraviglio che non sia saltata fuori prima ;-)
-- 
Lawrence - 
http://www.oluyede.org/blog
http://www.neropercaso.it
"Nothing is more dangerous than an idea
if it's the only one you have" - E. A. Chartier

 erroneamente lasciato cosi' solo per "incuria"?
...
credo che sia una ipotesi non del tutto da scartare...
avete presente quando netbeans/eclipse o altri suggeriscono:
right-click automatic fix, 'surround with try/catch' ... sembrerebbe
proprio quello... 
Ciao Gianmarco