Newsgroup: it.comp.appl.access
Titolo: Come rilevare numero di riga su gestione errori ???

Sarebbe utile, nell'intercettazione di un errore, poter sapere anche a che 
riga e' intervenuto
Nelle proprieta' dell'oggetto Error non esiste il numero di riga
Sapete se sia possibile visualizzare anche questo valore, tipo la funzione 
ERL del VB per capirci
Ciao
RobertoA


Non è possibile che io sappia.
@Alex


Si fa proprio come faresti in VB (almeno credo, visto che la libreria dovrebbe 
essere la stessa): usi il metodo Erl(), che però è normalmente nascosto dal 
visualizzatore oggetti.
Eccoti un esempio:
""""""""""""""""""""""""""""""""""""""""""""""""
Sub ProvaERL()
On Error GoTo Err_ProvaERL
 
10    Err.Raise 1
Exit_ProvaERL:
    Exit Sub
Err_ProvaERL:
    MsgBox Err.Description & vbCrLf & "avvenuto alla riga " & VBA.Information.Erl
    Resume Exit_ProvaERL
    Resume
End Sub
""""""""""""""""""""""""""""""""""""""""""""""""
Unico requisito per poter utilizzare correttamente il metodo Erl() è impostare 
i numeri di riga.
Come vedi nel mio esempio, io ho utilizzato il numero riga solamente dove 
c'è l'errore: è ovvio che questa non è una gestione corretta, visto che, 
a priori, non puoi sapere la riga dove si verificherà l'errore. Se così fosse, 
l'uso di Erl() si potrebbe sostituire tranquillamente con una gestione mirata 
di quell'errore.
Devi, quindi, mettere i numeri di riga su tutte le righe del codice (te lo 
sconsiglio).
--
PBsoft di Gabriele Bertolucci
www.pbsoft.it
skype:pbsoftsolution

Aggiungo solamente che, se proprio vuoi seguire questa strada, puoi utilizzare 
gli MZ-Tools for VBA (
http://www.mztools.com/v3/mztools3.htm
) per aggiungere 
e togliere automaticamente i numeri di riga da una procedura.
E' anche ovvio che questo poi non è sufficiente, a meno che tu non gestisca 
il versioning di un applicativo: se non lo fai rischi di ottenere un messaggio 
di errore che fa riferimento ad una riga dove, invece, trovi tutt'altro codice.



Non lo sapevo direi che è pure interessante... personalmente
preferisco evitarlo e passare ad un LogFile il Function(Sub)Name ed i
Parameter eventuali in modo da riproporre il problema e con il Debug
StepByStep mi trovo da solo il punto di rottura...
Mi pare serva a poco, e concordo con le tue osservazioni in merito
alla necessità di Numerare TUTTE le righe...
@Alex



==========================================
Mi pare serva a poco ????
Ma allora come fate voi a sapere dove si pianta un programma o dove salta 
via a causa di un errore ?
Se il cliente vi chiama e vi dice
"Ahooo, uarda ghe seee pianta sullaaaa Form_PincoPalla, cooll'erroreee 
nummero ducentoventisetteeeeeee"
e voi magari provate a riprodurre l'errore ma da voi non si pianta, come 
minghia fate ?
Gli dite "ascolta guarda che il problema lo fa solo sul tuo pc, sul mio 
funziona tutto"
E dopo come fate a farvi dare i dindini che vi deve ?
Ciao e grazie
RobertoA

 tutt'altro codice.
Molto interessante, grazie molte
Posso sapere voi come vi comportate per la gestione errori ?
Tracciate solo routine e numero/descrizione errore o cos'altro ?
Ciao e grazie
RobertoA

 Tracciate solo routine e numero/descrizione errore o cos'altro ?
Per quanto mi riguarda, le mie applicazioni sono abbastanza piccole da non 
richiedere una minuziosa gestione degli errori (che, comunque, sarebbe sempre 
bene implementare!!!!!!).
Pertanto non gestisco un logfile, ma semplicemente visualizzo dei messaggi 
di errori personalizzati comprendendo ovviamente il numero e la descrizione 
dell'errore, ma anche il nome della routine nella quale l'errore si è verificato.


 E dopo come fate a farvi dare i dindini che vi deve ?
Il problema è a monte. Ciò su cui devi investire è l'analisi.



E' chiaro che se stiamo parlando di acchiappare errori, vuol dire che sono 
sfuggiti dalle previsioni iniziali di flusso del programma
Lo so anch'io che se lo studi meglio quel flusso, magari ne puoi prevenire 
molti di questi problemi
Ma per gli errori rimanenti ???
Oppure nei vostri programmi non succedono mai ?
Nel lontano, credo 1980, quando tornavo da scuola, con somma eccitazione 
pestacchiavo i tasti di un glorioso Sinclair QL
Era dotato di un Basic integrato nel sistema operativo, che permetteva 
sostanzialmente di realizzare qualsiasi tipo di applicativo
Bene, l'autonumerazione delle righe, in abbinamento alle procedure di 
gestione degli errori, era una delle cose piu' pratiche in assoluto
Ti permetteva di beccare all'istante la linea difettosa, sto parlando del 
programma compilato, non all'interno dell'ambiente di sviluppo
Posso credervi se mi dite che non usate questa funzionalita' perche' 
attualmente nell'ambiente vba integrato in Access non e' supportato, ma se 
continuate a dirmi che vi sembra di nessuna utilita' allora mi sembra che vi 
ostinate a negare l'evidenza
L'evidenza dell'utilita' di una gestione errori migliore di quella 
attualmente disponibile
Ciao
RobertoA

 RobertoA
Ciao.
-- 
Sergio MAZZA 


Nei miei succede sempre..., però secondo me potresti vedere la cosa da
un'angolazione diversa, mentre ti sei fissato con il numero di
riga...!
Ti ripeto la mia modalità(che non è detto sia la migliore, ma è quella
che uso e che mi permette di trovare errori)...!
Innanzitutto come ti ha detto Gabriele le routine andrebbero ben
strutturate, riutilizzabili pertanto studiate bene, corte quanto più
possibile e spezzandole per l'ottimizzazione del flusso...!
Ogni Function/Sub deve avere una gestione errori globalizzata in un
Modulo, vale a dire che oltre gestire l'errore in locale invia ad una
Sub il Trace dell'errore...
Questa Sub mi stampa su un LOG i dati che io ritengo utili a fare
diagnostica...!
Quali sono questi dati...?
Di certo quelli che mi devono consentire di ricreare l'errore, quindi:
1)NomeForm(anche se la routine è Private la gestione è Globale)
2)NomeSub/Function
3)UserName
4)Permissivi
5)Elenco parametri valorizzati
6)N°errore e Descrizione
Con questi dati ho la possibilità di isolare la Sub/Function che mi ha
generato errore
e cercare di riprodurlo lanciandola dalla finestra immediata e
passando i parametri
salvati nel Log dopo aver impostato la condizione di test...
Ti assicuro che mi trovo bene e non mi serve a nulla un numero di
riga, infondo ricorda che non si programma più in modo sequenziale,
questa è programmazione ad oggetti ed ha veramente poco senso...
@Alex

 righe ma non puoi fare l'esecuzione passo-passo... Un bagno di sangue...
E questo cosa c'entra col nostro discorso ?
Nessuno nega l'utilita' del debug all'interno dell'ambiente Access
Solo sto cercando di convincerti che avere un'informazione come la riga 
precisa dell'errore e' molto ma molto meglio che non averla
Potendola avere
Ciao
RobertoA

questa č programmazione ad oggetti ed ha veramente poco senso...
E questo che c'entra ?
Sapere che il problema e' nell'ogggetto X invece che alla dodicesima riga 
dell'oggetto X ti sembra meglio ?
Boh, non ve capisco ahh
Ciao
RobertoA

 RobertoA
Roberto non stiamo parlando di "patate lesse" ... il SW e la matematica non
sono OPINABILI
e una Routine da noi sviluppata non è e non può essere Hardware
dipendente...(a meno di scendere li livello come linguaggio di
programmazione, ma decisamente non è il nostro caso) quando si sviluppa ci
sono paletti inderogabili.
Gli errori delle Routine che sono definibili BUGS sono solo ed
esclusivamente un errore di programmazione, e sono sempre riproducibili,
ovviamente se hai sviluppato bene(non sottovalutare questo aspetto non sono
molti che scrivono bene il codice, e per bene non intendo BELLO ma
funzionale)...
Se hai dubbi su questi concetti oppure se hai opinioni diverse sei libero, e
non sono certo io a volerti convincere, ma credo tu abbia concetti
decisamente discutibili sulla programmazione in genere.
Per finire l'indice di riga non serve a nulla pechè come ti ripeto questa è
programmazione ad OGGETTI spero ti sia chiara la differenza, il NOMEOGGETTO
è proprio in linea con il metodo di sviluppo OOP che, sentendo le tue
svariate domande, dubito tu abbia chiaro... ma è di certo una mia personale
opinione.
-- 
@Alex (Alessandro Baraldi)
---------------------------------------------------------------------------
http://www.sitocomune.com/
http://www.alessandrobaraldi.it
---------------------------------------------------------------------------

 RobertoA
Roberto questa affermazione ultima mi indispone in modo notevole(anche se
non è vero...)
Sei tu a fare una domanda e vuoi convincere gli altri ....??? Ho notato
questo atteggiamento in altri
tuoi quesiti...
Ma che domandi a fare allora se la risposta migliore è la tua...???
Nel NG non si deve convincere nessuno... l'unica cosa che si può fare è
confrontare la
propria tesi con quella di altri.
Saluti


 Boh, non ve capisco ahh
e che quando ci si mettono sono piu' "tosti" del carborundum. E adesso 
stanno a fa la volpe e l'uva. Vaglielo a spiegare al Baraldi del perche' 
sotto l'ambiente java se so inventati quel "sarchiapone" del log4j e del 
perche' in errore restituisce l'intero stack di chiamate. Tieni duro! 
(non avercelo pero').
-- 
ac
y-1=x

 y-1=x


 propria tesi con quella di altri.
"..che domandi a fare allora se la risposta migliore è la tua...???.."
Guarda che ho chiesto COME leggere il numero di riga che produce un errore
E della risposta ringrazio molto
Non ho chiesto lumi sulla convenienza di usare tale informazione
A mio parere, la convenienza e' ovvia
A vostro parere, avere questa informazione oltre alle altre, non serve
Questa mi sembra sia la sostanza
E non mi dilungo sul "..non si deve convincere ..." perche' altrimenti non 
la finiamo piu'
Ciao e grazie
RobertoA

 Potendola avere
Io non voglio convincerti di nulla; ti porto solo delle mie esperienze, dove 
attualmente il sapere quale numero di riga è andato in errore non mi serve.
Mi serve, invece, il nome della routine e i dati in transito; perché il più 
delle volte (almeno per quanto mi riguarda) gli errori erano dovuti da 
valori non adatti all'elaborazione.
Corretti gli errori e vincolato l'utente ad inserire dati significativi; 
l'errore è sparito.


 l'errore è sparito.
Per 'attualmente' immagino ti riferisca ad asp / 
asp.net
 ?
E anche qua, il valore della riga sarebbe utile, capisco che il problema 
possa essere dovuto a valori non adatti all'elaborazione, ma finche' sti 
benedetti valori non li utilizzi in qualche istruzione, nissciuno se ne 
accorge del contenuto sballato
E quindi ricadiamo sul fatto che "piu' informazioni hai" e' meglio di "meno 
informazioni hai"
Ciao
RobertoA 

 (non avercelo pero').
Groan ... per come s'è evoluto il Thread parrebbe che per debuggare
un'applicazione (o individuare la causa di un errore Runtime da un Cliente)
serva chissà che.
... non è così orcoccann!    ;-)
Saluti.

 "meno informazioni hai"
Ma sě; questo lo dico anch'io e il DE CURTIS, ma non tutto č 
significativo/utile alla risoluzione del problema.
Probabilmente io sono per la prevenzione dei problemi; piů che cercare la 
causa dopo con i mille strumenti di debug.


 ... non è così orcoccann!    ;-)
....per una volta che rispondo a qualcuno......sigh.......


 Saluti.
@Alex

 causa dopo con i mille strumenti di debug.
Io invece sono per la prevenzione e per la ricerca post-errore
Basta ohhh, morta qua
Ciao
RobertoA