Newsgroup: it.comp.appl.access
Titolo: Una domandina su "on error goto ..."

Se faccio, in una maschera, all' evento click di un tasto :
private sub tasto_click()
on error goto errore
dim x as long
mia_proc()
errore :
fai qualcosa
end sub
private sub mia_proc()
on error goto errore
...
errore :
fai qualcosa
end sub
*se* si verifica un errore in mia_proc(),
la procedura tasto_click() non lo rileva, giusto ?
Cioe' come dire ... L' errore e' *locale* alla procedura
in cui si verfica, non si "propaga" all' esterno, giusto ?
Se cosi' e', non si potrebbe mettere l' oggetto err sotto
withevents a livello di modulo di maschera e intercettarlo
ovunque avvenga ?
No, vero ?


Credo tu non abbia le idee chiare.
Se l'errore è nell'Evento CLICK ovviamente quello che accade in una
Procedura esterna non viene segnalato all'interno di CLICK
ma nella Procedura avrai una GESTIONE ERRORI... e quando si chiamano
procedure esterne si sfrutta di solito una FUNCTION
anche se non deve restituire dati proprio perchè restituisca TRUE se
va a buon fine e FALSE se ad esempio non va a buon fine
in caso di Errori...!
Private Sub Button_Click()
   On Error goto Error_Handler
    ....
   If NomeProcedura()=False Then
      Exit Sub
   Else
      ' Fai quello che serve
   End If
   Exit Sub
Error_Handler:
   'Gestione Errori
End Sub
Ciao
@Alex

 Procedura esterna non viene segnalato all'interno di CLICK
Ecco, fermati qui.
Quindi mi confermi che l' errore in una procedura esterna
non si propaga.
Ovvero asserzione :
" l' evento errore non e' intercettato da alcuna procedura, SE NON
da quella in cui l' errore s'e' verificato".
Bene. Stabilito. Perfetto. Grazie.
Ora domanda :
secondo te e' possibile mettere sotto evento, nel modulo della
form,  l' oggetto ERR, in modo da intercettare centralmente qualsiasi
errore avvenga in qualsiasi parte della form e/o in qualsiasi routine
chiamata dalla form ?
[si] , [no]  mettere crocetta.
Scherzo, non ti irritare ... :-)

 Scherzo, non ti irritare ... :-)
Non mi irrito.
@Alex

Personalmente ci sono diverse scuole di pensiero su >questo modo di gestire gli errori...
Capisco.
Secondo te qual' e' il modo migliore di procedere ?

> Secondo te qual' e' il modo migliore di procedere ?
Dichiari Sub Pubblica in qualche modulo esterno :
Public Sub PrgErrore(xProveniente As String, xTipoErr As String, )
'ovviamente puoi inserire il risultato in un LOGFILE o in una
tabella...
' per semplicità ora ho usato un Msgbox
Msgbox "Errore proveniente da :  " & xTipo & vbcrlf & "Tipo Errore : "
& xTipoErr
End Sub
in ogni Form o modulo o quel che ti pare :
On error Goto Err :
...
...
...
Err :
Call PrgErrore("Apertura Maschera1", err.Number & " - " &
err.Description)
d+ non puoi...
ammenochè non dichiari una variabile pubblica che popoli per ogni riga
di codice e la passi come paramentro nel tipo di errore... a quel
punto sai anche l'errore da dove è nato...però è ovviamente un pour
parler perchè non è pensabile per ogni riga di codice popolare una
variabile per gestire un errore... nel senso è fattibile, ma è un
assurdità.

ammenochè non dichiari una variabile pubblica che popoli per ogni >riga di codice e la passi come paramentro nel tipo di errore... a >quel punto sai anche l'errore da dove è nato...però è ovviamente un >pour parler perchè non è pensabile per ogni riga di codice popolare >una variabile per gestire un errore... nel senso è fattibile, ma è >un assurdità.
Ma c'e' una segreta possibilita ... ;-)
Guarda questo frammento di codice :
sub ( ... )
on error goto errore
dim x as ...
dim y as ...
10 x = y + 1
20 if x > y/2 then ...
30 ...
40 ...
errore :
msgbox(erl)
End sub
Ebbene, la ERL e' una antica "funzione"
che torna, udite udite, il numero della linea
dove s'e' verificato l' errore. Ed e' visibile
in ogni punto dell' applicazione.
Infatti :
Il VB ancora supporta la numerazione delle
linee. Provare per credere.
Alla luce di questo fatto, forse qualcosa di
piu' si puo' fare. Dimmi, dimmi.


Si, va bene Erl, ma la riga di quale codice è andata in errore?? Nel
senso, del "CLIK" del pulsante, o dell' "APERTURA FORM"?... Erl tiene
conto del numero di riga indipendentemente dal codice su cui ricade...
quindi cmq ne sapresti quanto prima se non passi il valore "titolo"
alla variabile della Public Sub di cui prima...

ma la riga di quale codice è andata in errore??
Basterebbe numerare in questo modo
(salvo errori ed omissioni, ma non sei stupido e
il "concetto" ti sara' subito chiaro) :
1)
Assegnamo ad ogni evento un numero progressivo
(come d' altra parte fa la macchina al suo interno)
Es 10000, 10001, 10002, 10003, ...
2)
Assegniamo a ogni modulo di form un numero progressivo
Es 20000, 20001, 20002, 20003 ...
3)
Assegnamo a ogni modulo bas un numero progressivo
es 30000, 30001, 30003, ...
Se stiamo nell' evento (ad es. click() = 10000) della
maschera  20000
ogni linea di codice di quell' evento sara' (gli spazi solo per
chiarezza) :
20000 10000 00001 (prima linea)
20000 10000 00002 (seconda)
...
(si possono fare anche numeri piu' corti, se il programma e' piccolo)
Con un po' di disciplina "organizzativa", non e' un grosso lavoro a
pensarci bene.
Nella gestione errori basterebbe trasformare Erl in stringa e
decodificare con una split( ) per sapere dove e' avvenuto l' errore
con
ESTREMA precisione.
No ?

 No ?
Ed era quello che ti ho suggerito molte righe sopra, non ti pare?


A proposito, ma lo sai vero che se usare Erl() senza "NUMERARE" a
manina le righe del codice, serve a nulla?... ti restituirebbe sempre
"0"...
Quindi dovresti a mano dire al sistema il numero della riga,
altrimenti Erl non serve a niente...
il che va bene per codici piccoli, ma pensa a codici di "n mila
righe"... numerate progressivamente... basta aggiungere qualcosa in
mezzo al codice per dover rinumerare a manina il codice intero... non
è tanto simpatica la cosa... tranne se... ;)
...visto che sono buono e bravo, ti segnalo questo...
http://www.mztools.com/v3/download.aspx
così eviti di fare le cose a manina, e sfrutti qualche Tools ad hoc
per VBA ;)

 No ?
Provalo con un MDE....
A prescindere di avere il feed del LineCode a cosa serve alla fine...?
Ripeto che manca lo stack degli errori, quindi la cosa resterebbe fine
a se stessa....
Se è per fare debug, conviene realmente lasciare la gestione errori
locale, ma inviare ad un LOG
NomeForm, NomeFunction, Parameter, Err.Num ed Err.Desc ed altri
parametri eventualmente utili...
Magari mi sfugge qualche tua più lungimirante considerazione...
@Alex

 Magari mi sfugge qualche tua più lungimirante considerazione...
No macche' , ma quale lungimirante ... :-)
Io qua scrivo per scambiare idee e imparare qualcosa.
Non sono nessuno e non mi sento nessuno.

Cioe' : perche'  :
 >"se non c'e' lo stack degli errori la cosa sarebbe fine a se stessa"  ?
perchè cmq non potresti intervenire... se non andando nell'MDB...

 il progetto compilato in modo non modificabile...
... Capisco.
E' stand alone ? Cioe' e' eseguibile anche senza
Access ? Come fosse un progetto VB, per intenderci.