Newsgroup: it.comp.lang.visual-basic
Titolo: [DEBUG] On Error GOTO... Questione di stile

Salve a tutti
Ho sempre considerato l'uso di On Error Goto da evitare, ma in questi
giorni ho quasi cambiato idea.
Probabilmente è questione di elasticità mentale, ma mi domando come si
comportano gli altri programmatori. Non sempre "On Error Resume Next"
rende più elegante e leggibile il codice, specialmente quando le
necessità di gestione dell'errore richiedono il rientro nella procedura
più volte, fino ad una esecuzione priva di errore. Però rende meno
confusionario il codice quando gli errori da gestire sono più di uno.
Che ne dite? Ci sono due esempi, qui sotto: mi sembra che il secondo sia
meno "inquinante". Nel codice principale non si sente che il vago odore
di qualcosa di estraneo alla procedura, essendo raggruppato e
centralizzato in coda. Oltretutto, non ci sono altrre tipologie di
procedura che agiscono in questo modo (con i salti a etichetta) e la
pulizia del codice mi sembra buona ugualmente.
Qui lo dico e qui lo nego. Potrei cambiare idea fra un po'.
Esempio [1]:-----------------------
On Error Resume Next
While Err <> 0
	Err.Clear
	... 'Inizio Proc1
	...
	... 'Probabile errore
	If Err Then
		Quel che c'è da Thenere1
	End If
Wend
While Err <> 0
	Err.Clear
	... 'Inizio Proc2
	...
	... 'Probabile errore
	If Err Then
		Quel che c'è da Thenere2
	End If
Wend
Esempio [2]:-----------------------
	Dim iErrPosition As Integer
	On Error Goto ErrorTrap
Resume1:
	iErrPosition =1
	... 'Inizio Proc1 
	...
	... 'Probabile errore 1
 
Resume2:
	iErrPosition=2
	... 'Inizio Proc2
	...
	... 'Probabile errore 2
ErrorTrap:
	Select Case iErrPosition 
		Case 1
			... 'Repair
			If [Scelgo Retry] Then
				Resume Resume1
			Else
				Resume Next
			Endif 
		Case 2
			... 'Repair
			If [Scelgo Retry] Then
				Resume Resume2
			Else
				Resume Next
			Endif 
	End Select 
---------------------------------------------------
Flavio Ronco
-- 
f.ronco@*NonMiServeNiente*
flashnet.it
http://www.metabrains.com
  [Under Construction]
-------------------------------------------------------------
"Che pubblico in gamba! Se ci dite dove lavorate,
domani mattina se abbiamo tempo vi veniamo a vedere"
[Paolo Rossi]

Io personalmente uso da sempre il secondo esempio, lo trovo molto pulito
(nonostante la presenza di goto vari) e chiaramente leggibile, avendo la
gestione dell'errore completamente separata dal codice vero e proprio !!!
--
Ciaps
Stracca
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Cerca le risposte alle tue domande sul Sito Comune del
newsgroup it.comp.lang.visual-basic: 
http://www.murialdo.it/it_lang_vb
Magari prima leggi l'Help in linea!
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

 gestione dell'errore completamente separata dal codice vero e proprio !!!
Come pensavo, e avevo anche scritto, salvo poi avere dubbi (periodo di
incrollabili certezze, questo)
Io invece ho sempre usato il primo esempio, coi loop...
Un po' di post come il tuo e cedo.
Ciao
Flavio


 Esempio [1]:-----------------------


Personalmente la scelta dipende da come devo trattare l'errore, se in base
al tipo errore devo fare qualcosa allora uso il secondo metodo se invece
l'errore puó presentarsi ma non mi é indispensabile gestirlo uso il secondo.
Un classico esempio di uso del primo caso é quando ho una custom collection.
Es.
 Public property Get Item(Key as string) as CMyClass
  On error resume next
  Set Item=moCol(Key)
 End Property
Set MyObj=MyCustCol.Item("Test")
If MyObj is nothing then
    ... object doesen't exists
EndIf
Immagina la stessa cosa fatta col secondo metodo...
Generalmente preferico codice che sia piú facile da gestire, anche se a
volte non é sintatticamente perfetto.
Ciao,
Corrao

gestione dell'errore completamente separata dal codice vero e proprio !!!
Concordo su questo...
Anch' io faccio sempre cosi e ho sempre evitato la istruzione resume next
solo se non e' necessario...
Ricordate sempre di aggiungere alla fine se la gestione di errore non
prevede un certo errore trappato...
Se si deve scrivere servizi NT usando il modulo ntsvc.ocx la gestione
degli errori va curata al massimo...
-- 
Sidewinder  
---------------------------------------------------------------------
It is often the case that the man who can't tell a lie thinks he is the best
judge of one.
		-- Mark Twain, "Pudd'nhead Wilson's Calendar"
---------------------------------------------------------------------

 giorni ho quasi cambiato idea.
Io non lo uso mai, solo On Error Resume Next, e qualche if, di salti nei
miei programmi non se ne parla proprio...sarà colpa della scuola? dei
prof che se solo provavi a inserire un goto (se non in assembler) ti
tacciavano della temutissima programmazione a spaghetti? 
Meno salti ci sono è più lineare è il software... almeno così mi
dicevano
Ciao 
:-) Hd (-:

 wrote in message
3871F4E9...@TOGLI.freemail.it...


 wrote in message
84st4e$ca6$1...@pegasus.tiscalinet.it...


 verificato che tipo di errore e quante volte mi si è presentato 
!!!
Io invece solitamente destino un Flag (ErrorFlag) a contenitore di 
errore. Ergo, uso 'on local error goto LabelErrore' (local perchè 
ogni routine di regola necessita di controlli diversi dell'errore) e 
tale pseudoroutine controlla che genere di errore accade. Ritorna in 
questo caso con il flag settato e con un bel resume next. Il 
programma reagisce quindi diversamente seguendo questo flag. In 
questo modo intercetto errori 'particolari', e non ovviamente quelli 
insiti da errori di programmazione e non perdo la strutturalità del 
listato. 
---
News2000 1.0b Beta tester version 
http://socket2000.8m.com

 Un po' di post come il tuo e cedo.
Cedi.
Pare che siamo tutti d'accordo, On Error Goto non è mica Satana.
Anch'io non ne uso altri, di goto, ma in questo caso...
Bye, G.
--
---------------------------------------------
    Le risposte alle tue domande le trovi
    sul Sito Comune di questo NewsGroup:
 
http://www.murialdo.it/it_lang_vb
       ... e nell'help in linea !
---------------------------------------------
Real E-address: 
gaet...@hotmail.com

 tacciavano della temutissima programmazione a spaghetti?
Mmmmmmh... lo spaghetto è un piatto multithread, questo lo sapevano i
tuoi docenti? Il fatto è che quasi tutti risucchiano lo spaghetto (goto)
e pochi roteano la forchetta (loop) soprattutto se autodidatti. Beh, io
sono autodidatta e sto per cominciare a risucchiare.
Che bello, però, avere chi ti cazzia se programmi male. I miei prof mi
cazziavano perché studiavo il Basic del Commodore PET32 (32K di RAM) al
posto di Topografia.
Al dio là della questione debug, ci sono problemi che si possono
risolvere solo con cadute stilistiche.
Con VB è facile avere problemi di prestazioni, soprattutto se si
utilizza in modo massiccio (per quel che VB consente) l' OOP, e
moltissime volte capita di scrivere codice da sindrome di Stendhal, per
poi cominciare a maneggiare in tutte le maniere pur di guadagnare
qualche millisecondo all'interno di un loop.
Credo che i piedi per terra non ce li faccia mettere la superficialità
nostra, bensì il livello di prestazioni (in tutti i sensi) dello
strumento che usiamo.
Flavio Ronco


 ogni routine di regola necessita di controlli diversi dell'errore) 
A *prosito*, ma Local non è implicito? Su un articoletto di MSDN, tratto
da un _Advanced qualchecosa VB_
si interpreta che Local si comporti come Let, e quindi non c'è
differenza. In base a ciò non ho mai fatto prove, nella documentazione
non ho trovato tracce. Che fa 'sto Local, in definitiva?
Ciao


 non ho trovato tracce. Che fa 'sto Local, in definitiva?
Fa in modo che la routine di gestione errori sia 'locale' solo alla 
procedura nel quale è inserita.





 vbCritical: Debug.Print error$: Resume Next
 mainErrHandler:
 If Err.Num then
     error$ = "Errore di runtime " & Err.Num & ": " & vbCrLf  & Err.Description
     Debug.Print error$
     MsgBox error$, vbCritical
     Resume Next
 End If
Così è un po' più pulita... e magari può esserti utile anche questa:
Sub AddLog(riga$)
      On Error GoTo problema
      Dim libero As Integer
      libero = FreeFile
      Open App.Path & "\errori_log.txt" For Append As #libero
      Print #libero, riga$
      Close libero
      Exit Sub
problema:
      MsgBox " Errore " & Err.Number & "  " & Err.Description & vbCrLf & _
      Err.Source & " " & " nella routine AddLog, testo: " & riga$
      Err.Clear
      Resume Next
End Sub


 vbCritical: Debug.Print error$: Resume Next
Sì, però qui il problema vero è il rientro dall'errore e, soprattutto la
possibilità di retry dell'operazione che ha generato l'errore. Un
problema come questo difficilmente si risolve senza la provvidenziale
caduta di stile dell'on error goto.
Che poi le cadute di stile non sono altro che aggiunte di complessità
(soggettiva) al programma.
Flavio Ronco


 End Sub
Che chiarezza ... che ordine ... che precisione ... se non fossi un uomo ti
farei una proposta ..... FERMIAMOCI QUA' !!!






 farei una proposta ..... FERMIAMOCI QUA' !!!
Uehilà, proposte di che tipo ? Stai attento che mia moglie sosptetta
già di Ettore, se ti ci metti anche tu, sono nei guai !
 -_________^
