Newsgroup: it.comp.lang.visual-basic
Titolo: VisualBasic6 - Gestione ottimale dell'errore

Ciao. Ho un programmino in Visual Basic 6 il quale, tramite un timer, va
ogni tot di tempo a verificare che un processo esista ancora, e se
questo ha generato dei file in output, li legge e li processa.
Normalmente funziona senza problemi, sta di fatto che una volta sono
tornato ed il programma era bloccato con una finestrina tipo "errore
xxx". Mi sono fatto prendere dal panico dato che dovevo rimetterlo
subito in esecuzione, ho cliccato OK senza prendere nota dell'errore, il
programma e' uscito ed io l'ho riavviato immediatamente.
Ora vorrei evitare problemi di questo tipo in futuro. Ho inserito
all'inizio della procedura del timer:
Private Sub Timer1_Timer()
     On Error GoTo ErrorTimer
... normale corpo della funzione ...
     Exit Sub
ErrorTimer:
End Sub
Come potete immaginare la gestione dell'errore non e' ottimale, questa 
tecnica *dovrebbe* solo permettermi di non bloccare il programma quando 
qualcosa va storto. Tuttavia gli errori vanno analizzati e risolti.
Io suppongo che possa capitare un errore quando il processo esterno sta 
ancora scrivendo su un file ed io tento di leggerlo dal visual basic. 
Circostanza rara ma che puo' succedere. Questa tecnica mi permetterebbe 
di saltare per un secondo l'analisi e di riprovare dopo un po'.
Tuttavia come anticipavo vorrei qualcosa di piu' "robusto". Mi 
piacerebbe loggare gli errori su un file da guardare ogni tanto e sul 
quale ragionare. L'oggetto "err" contiene una serie di informazioni 
utili; il problema e' il seguente: se apro un file, ci scrivo, etc, come 
posso essere sicuro che non venga sollevato un errore proprio nella 
routine di gestione dello stesso? dalla padella alla brace...
Ho letto un thread di qualche tempo fa in cui appariva quella che 
potrebbe essere una risposta, ovvero di settare On Error Resume Next 
subito dopo la label "EndTimer". Cosa ne pensate? Non e' comunque una 
soluzione ottimale credo...
Qualcuno ha una tecnica infallibile per il log degli errori :) ???
ciao e grazie!
Alessio Sangalli

 errori :) ???
Infallibile no!...di infallibile ce ne è uno solo...e fra 18 giorni è il suo
compleanno!
cmq
On error resume next
ogni volta devi fare qualcosa di critico
If err.number <>o then
   ... processa errore
   ... contromisure etc etc
end if
-- 
Il Wodkino Nazionale è a : 
www.martek.it
Pagina Vb/Bestiario/Lamer Experience :
http://www.martek.it/go.asp?portamia=2
 Demo classe vb.NET :
WodkaThumb 
www.villaceleste.it
  click su "spippolando e
Programmando"
---
Messaggio scannerizzato e certificato "Virus free" da AVG free edition.
Checked by AVG anti-virus system (
http://www.grisoft.com
).
Version: 6.0.806 / Virus Database: 548 - Release Date: 05/12/2004

 il suo compleanno!
Mi mandi la torta?
Alberto
--
E tutto mi sembrava andasse bene...

 end if
aiutami a capire meglio, nel mio caso mi consiglieresti di fare lasciare 
"on error resume ErrorLabel" e dentro la label mettere "on error resume 
next"; dopodiche', nella routine di gestione dell'errore, controllare il 
valore di err dopo ogni azione tipo apertura files etc?
Dimmi se ti ho capito bene :)
grazie!
ciao
as

 Wodka40° wrote:
non proprio
non avendo il try in vb6 puoi fare in 2 modi
Centralizzare chiamando una tua "zona"
On error GOTO
oppure fregandotene e decidendo volta volta interrogando l'oggetto ERR
On error resume next
If err.number=123 then
        .....aiuto esplode il pc
endif....
Come faccio io?
Mi son fatto una mia classettina...ma va bene anche una
function....qualsiasi cosa ti faccia sentire a tuo agio...
che prende e scrive in un file una specie di log degli errori
ad esempio una function
Public Function LogErrori() As Boolean
'File di log errori
Dim Fpath As String
Dim nFile As Integer
Dim DatoScrive As String
Fpath = App.Path & "\logerr.txt"
nFile = FreeFile
DatoScrive = CStr(Date) & " " & CStr(Time) & " - "
DatoScrive = DatoScrive & "Errore: " & CStr(Err.Number) & " , "
DatoScrive = DatoScrive & Err.Description & " , "
DatoScrive = DatoScrive & CStr(Err.Source)
Open Fpath For Append As nFile
Print #nFile, DatoScrive
Close #nFile
LogErrori = True
End Function
scive nella dir del programma un file logerr.txt
cambia il modo di richiamarla....
in genere se una cosa è critica è meglio che salti ad una zona del tuo
codice che decide se bloccare e terminare la procedura...pensa ad una serie
di aggiornamenti sui record o su varii recordset....
Se la cosa è "meno grave"...puoi tranquillamente continuare e far apparire
un warning a video....
Ad esempio se fai una calcolo=12/0...perchè bloccare?....fai un bel msgbox
"Asino 4 in matematica" ...assegna per convenzione calcolo= 0 e continua!
Sempre che la conseguenza del continuare non sia grave!
Nel tuo caso...presumo che un bel resume next...ed una precisa generazione
di log errori sia utile!
OCCHIO però!
Non tutti gli errori son intercettabili...qualcuno veramente carogna non lo
intercetti...per questo non esiste un sistema infallibile....
ad esempio MSDN recita:
"......
Nota   Gli errori di sistema che si verificano durante chiamate a librerie a
collegamento dinamico (DLL) Windows non sollevano eccezioni e non possono
essere intercettati con i sistemi di intercettazione degli errori di Visual
Basic. Quando si chiamano funzioni di DLL, è necessario controllare tutti i
risultati per verificare se le chiamate hanno avuto esito positivo o
negativo (in base alle specifiche API) e in caso di esito negativo sarà
necessario controllare il valore della proprietà LastDLLError dell'oggetto
Err.
....
"
e occhio ancora ad errori del tipo:
on error resume next
do
calcolo=valore/0(o espressione che abbia questo effetto)
if err<>0 then
    calcolo=0
    msgbox "Asino"
endif
valore=valore+1
loop until calcolo=129


 loop until calcolo=129
logicamente č uno stupido esempio...č esageratamente didascalico!!!
-- 
Il Wodkino Nazionale č a : 
www.martek.it


 ha scritto nel
messaggio news:31ltokF...@individual.net...


 del file di log puoi trarre info utilissime
Grazie, non sapevo che anche in VB si potessero numerare le linee come 
nel Basic normale!!!
ciao!
as


Ma ogni riga del programma come la numeri?
A mano o con qualche strumento automatico?
C'e' modo di 'individuare' la riga che ha attivato l'errore senza l'uso
della variabile ERL ?
Ciao e grazie
RobertoA

 ha scritto nel messaggio
news:320mheF...@individual.net...



Ma..ma...quanto sono lunghi sti programmi ?
Perche' se sono da una trentina di righe e' anche possibile andare a mano ma
se iniziano a diventare corposi allora c'e' di che disperarsi a scrivere
numeri di riga.
Io non ho ancora una soluzione al problema, sto pensando di realizzare un
programa solo per la numerazione delle righe dei form/moduli di un progetto.
Ciao
RobertoA

 programa solo per la numerazione delle righe dei form/moduli di un progetto.
Tranquillo, in realta' i numeri di riga per visual basic sono impostati
sotto forma di etichette.
Ne consegue che lo 'scope' delle etichette e' interno alle sub/function,
percio' puoi' tranquillamente iniziare da 0 in ogni routine e nel 
messaggio/log di errore ti porti appresso il nome del 
form/modulo/classe, il nome della routine e finalmente l'Erl.
-- 
ciao, hal