Newsgroup: it.comp.lang.visual-basic
Titolo: Uniformare i codici di errore

Salve!!!!!!
Ho un grosso problema nel codice.
Devo "uniformare" i codici di errore all'interno delle
varie DLL che compongono il progetto di cui mi sto
occupando.
Quando lavoro in Delphi, ho a disposizione una classe
Exception da cui derivare quello che mi serve e dare cosě
un certo ordine alla gestione degli errori.
Purtroppo lo stesso non vale per VB, quindi mi chiedevo
quale fosse secondo voi il sistema piů corretto per gestire la
cosa.
Partiamo dal concetto che l'idea di usare OnError GoTo non mi
emoziona particolarmente, quindi vorrei qualche nuova idea per
gestire la cosa.
Una delle cose che mi č venuta in mente č cercare di "prevenire" gli
errori, facendo in modo che non si verifichino proprio.
Verificando,per esempio, che un recordset non sia vuoto e cose cosě.
Voi come risolvete?
Fatemi sapere,
Andrea
P.S. Grazie in anticipo

Dimenticavo di dire che, benché non mi entusiasmi, qualora fosse
indispensabile, come fate a rendere "uniformi" i codici di errore?
Usate qualche metodo?
Io programmo in VB da pochi mesi, quindi non ho idea di
come si faccia :-)
Ciao
Andrea

 Voi come risolvete?
Io uso gli on error solamente quando proprio non si può evitare
l'imprevedibile, o per applicazioni unattended, per il resto cerco di
prevenire tutto, e preferisco, se c'è un errore, che la cosa appaia e che il
cliente me lo segnali.
Ciao
Alberto

 errori, facendo in modo che non si verifichino proprio.
ma questoio lo faccio sempre... mi pare la base del programmare
decentemente...
però uso anche gli "on error" purtroppo è l'unica possibilità fornita da VB
per trappare gli errori..
non so cosa intendi per uniformare... comunque io ho una classe che in
sostanza gestise gli errori,
in questa classe è definita una enumerazione che contiene i possibili errori
"non vb", i metodi della classe in pratica mi consentono di:
-gestire l'output dell'errore su file di log o a video o entrambi
-gestire gli errori trappabili da VB
-gestire gli errori "personalizzati"
alla partenza dell'applicativo creo un'istanza globale di questo ogetto che
verrà scaricata alla chiusura dell'applicativo...
spero di essere stato utile...
Davide

 indispensabile, come fate a rendere "uniformi" i codici di errore?
sinceramente, non capisco il senso della locuzione.....
intendo dire che, per quanto ne so, in vb gli errori hanno semplicemente un
numero ed una descrizione. Una serie di numeri è già "occupata" dal sistema, da
un certo numero in poi sono "liberi" per essere utilizzati dagli sviluppatori.
Se devi generare un errore in qualche sub o function, credo che vada bene anche
all'interno delle dll, ti limiti a fare un raiseerror indicando un numero che
verrà poi interpretato, eventualmente, dalla funzione chiamante.
Se intendevi una logica di classificazione degli errori del tipo (ipotizzando
numeri e descrizioni a caso, neh :-) )
10xx errore su database, suddiviso a sua volta in
1001 dati non presenti
1002 connessione non valida
1099 non altrimenti specificato
te la devi implementare da zero
hth, ma ho molti dubbi in merito :-)
--
Salutoni
Sergio

 hth, ma ho molti dubbi in merito :-)
Purtroppo ha confermato le mie perplessità.
Mi ha aiutato, ma solo nel senso che ora non ho
idea di come affrontare la cosa.
Ciao
Andrea

 implementano il mio stesso numero di errore?
perdonami.. forse non afferro io ma a cosa ti serve renderli univoci
rispetto a quelli di 3° parti?
nella tua dll il codice è tuo no? quindi gli errori che saltano su sono i
tuoi... basta stare fuori dal range di errori di vb e delle tecnologie che
usi nella DLL (es ADO).. o mi manca qualcosa?
:)
Davide

 implementano il mio stesso numero di errore?
questo lo ignoro.
nel senso: vb dice che i numeri di errore sono a disposizione dell'utente da un
certo punto in poi, però non c'è alcuna certezza che quei numeri non siano
utilizzati da qualcun altro.
Tu puoi decidere che nelle tue dll generi gli errori che vanno da x a y, se chi
usa le tue dll usa anche le dll di qualcun altro e per un qualche motivo i
codici si intersecano la cosa può essere fonte di problemi.
Una gestione dell'errore puntuale, cioè inserita in ogni singola routine,
dovrebbe "risolvere" il problema, perchè si potrebbe fare in modo che
all'interno della singola routine debbano essere gestiti gli errori di dll che
non entrano in conflitto tra di loro.
Curiosità: chi fornisce le dll si preoccupa di elencare gli eventuali errori che
possono essere generati?
--
Salutoni
Sergio

 ha scritto nel messaggio
news:C7%8a.2380$pG1....@news1.tin.it...

L'ipotesi di Andrea immagino fosse questa:
Dim c1 As New MiaDLL.Class1
Dim c2 As New TuaDLL.Class1
On Error GoTo TestErr:
c1.TestMe
c2.TestMe
TestErr:
MsgBox Err.Number & "-" & Err.Description
se io e te, che forniamo un componente a lui, usiamo gli stessi codici, come
capisci chi ha generato l'errore?
Ciao
--
Luca Dormio - 
luca....@tin.it
________________________________
"Marty, non stai ragionando in maniera quadridimensionale"
Dr. Emmett L. Brown

 errori che possono essere generati?
Per ora no, ma in un futuro non troppo lontano pretendero' una
lista _completa_ e _definita_ .
Ciao
Andrea

 Ciao
Ciao
Andrea

Siamo delle mozzarelle!!!!!!!
Ogni errore ha una proprietą "Source".
Basta usare quella :-)
ciao
Andrea

 come "messaggi" di Windows con la "RegisterWindowsMessage"?
Che ti cerchi delle grane senza motivo ;-)


 Ogni errore ha una proprietą "Source".
appunto č per questo che non capivo...
va beh... :P
Davide

 possono essere generati?
io lo faccio sempre... mi sembra il minimo....
Davide

 Davide
Andrea

 Spero non allo stesso modo di come fa MSDN...
nonrmalmente i miei codici di errore sono una enumerazione publica...
e poi comunque fornisco lista con breve dettaglio :)
Davide


Io ho seguito, nel definire le mie costanti di errore, un paio di concetti
di fondo:
1)
Sono tutti numeri negativi.
Siccome uso pochissime Sub e quasi solo Function, mi faccio restituire dalle
function, se non mi serve niente di particolare, un long che indica, ad
esempio, il numero di record elaborati, o il numero di cicli eseguiti,
ecc...
Quindi, se tutto va bene, ho un numero positivo (per la stragrande
maggioranza delle function). Se invece c'è un errore, la function
restituisce un numero negativo, che indica l'errore. Se non mi interessa
gestirlo, ma semplicemente sapere se c'è stato o meno un errore, devo
semplicemente fare un If Funzione()<0 then.
2)
Sono tutti potenze del due (col meno davanti)
Questo consente di poter comunicare più errori in un colpo solo,
semplicemente sommandoli.
Ad esempio, se -1 indica connessione non valida, e -2 indica errore di
apertura del recordset, la funzione Apri_Recordset mi restituirà -3.
Dalla procedura chiamante quindi saprò, con un semplice AND binario, quali
errori sono avvenuti.
Per il resto, credo che una enumerazione di 10-12 costanti sia più che
sufficiente a coprire tutti i casi più comuni. Se si vuole andare nel
dettaglio, io vado poi a leggermi la collection Errors.
Ciao
Alberto

 Alberto
Ciao
Andrea

 Posso rubarti queste idee?
Accomodati.
Se ne vuoi un'altra:
Scrivo TUTTO su un log.
Tutto.
Avvio, chiusura, apertura e chiusura di recordset, di connessioni,
esportazioni, importazioni, inserimenti, update, cancellazioni, cambiamenti
dei parametri, errori di rete, login, logoff, ecc...
Non puoi immaginarti che comodità sia per il debug.
Driiinnn....
"Pronto"
"Buongiorno. Ho un errore nell'inserimento di una nuova matricola. Il
programma si rifiuta..."
"Mi manda il pippo.log per e-Mail?"
"Certo, arrivederci"
Tadah... You've got new mail...
Salva allegati->Decrypt
Blocco note->Apri file
Azz... ma ha fatto il login con un utente non autorizzato a creare nuove
matricole...
Ecc....
Ciao
Alberto

 cambiamenti dei parametri, errori di rete, login, logoff, ecc...
Anch'io stò predisponendo un sistema simile... le funzioni mi dicono, "in
generale", solo se sono andate a buon fine o no... il perchè si legge nel
log (in certi casi posso ottenere, oltre al numero dell'errore e la
descrizione, anche il numero di linea!).
Btw il log è disabilitato di default e abilitabile dall'utente. E'
comodissimo anche in fase di sviluppo quando ci sono in gioco molte chiamate
di funzioni (magari in dll differenti): non serve più seguire con F8: si sa
subito dove mettere il breakpoint! ;)


Una variante sul tema di Alberto, che usiamo qui in un progetto recente, e
che magari solletichera' i tuoi gusti OOP :-)
Classe Status con alcune proprieta' tipo codice e descrizione e altro,
metodi del caso nonche' un evento di notifica che e' possibile consumare a
discrezione; per il codice usiamo anche noi un enum con valori 2^n per poter
applicare maschere di bit, nel nostro caso riserviamo i codici negativi agli
errori gravi (tipicamente problemi su DB) mentre quelli positivi sono per
notifiche di update, messaggi di avviso ecc..
Ogni classe e ogni form del progetto espone sempre una property pubblica di
classe Status; questo tra parentesi rende molto comodi alcuni passaggi di
informazioni tra i vari componenti, tipo:
Classe A chiama metodo di Classe B che avvia una form della GUI; se la form
deve notificare stati di avanzamento, oppure segnalare modifiche oppure
riportare errori, non serve altro che gestire l'evento della classe Status
"figlia" e/o "rimbalzare" i valori di status da un chiamante all'altro fino
ad arrivare all'origine
In questo modo evitiamo quasi del tutto l'uso di On Error, che viene
lasciato solo nelle implementazioni interne


Ciao
ciao

 Status senza l'uso di On Error?
Io aveevo capito "che viene lasciato solo nelle implementazioni interne",
quindi internamente alla classe.
Dall'esterno, si devono usare dei gran If then, come del resto si deve fare
sempre.
Ciao
Alberto

 ha scritto nel messaggio
news:Tii9a.178364$YG2.5...@twister1.libero.it...

Esattamente... all'esterno, laddove viene chiamato un metodo che puo'
restituire codici di errore/informazione vedi controlli del tipo:
Classe.Metodo
Select Case Classe.Status.Value
Case ERROR
    [...]
Case INFO
    [...]
Case OK
    [...]
'ecc...
oppure, se hai dichiarato una variabile WithEvents con riferimento impostato
sull'istanza di Status da controllare, ricevi le stesse info tramite
parametri dell'evento di notifica ... prolisso, certamente, ma molto sotto
controllo
