È possibile recuperare lo stack di chiamate a livello di codice in VB6?

Question

Quando si verifica un errore in una funzione, mi piacerebbe sapere la sequenza di eventi che la portano, specialmente quando quella funzione viene chiamata da una dozzina di luoghi diversi. Esiste un modo per recuperare lo stack di chiamate in VB6 o devo farlo nel modo più difficile (ad es., Registrare le voci in ogni funzione e gestore degli errori, ecc.)?

Answer 1

Sono abbastanza sicuro che devi farlo nel modo più duro. In un mio precedente lavoro, abbiamo avuto un processo di gestione degli errori molto elegante per VB6 con componenti DCOM. Tuttavia, è stato necessario aggiungere un codice molto ridondante a tutti i metodi, al punto che disponevamo di strumenti sviluppati in casa per inserirlo per te.

Non posso fornire troppe informazioni sulla sua implementazione (sia perché l'ho dimenticato per la maggior parte e c'è la possibilità che possano considerarlo un segreto commerciale). Una cosa che spicca è che il nome del metodo non può essere derivato in fase di esecuzione, quindi è stato aggiunto come variabile stringa (alcuni sviluppatori avrebbero copiato e incollato invece di utilizzare lo strumento e avrebbe portato a pile di errori che mentivano. ..).

HTH

Answer 2

Devi farlo nel modo più duro, ma in realtà non è tutto quello difficile ... Davvero, una volta che hai scritto il modello una volta, è un copia veloce / incolla / modifica per abbinare il nome della funzione nell'istruzione Err.Raise al nome effettivo della funzione.

Private Function DoSomething(ByVal Arg as String)

    On Error GoTo Handler

    Dim ThisVar as String
    Dim ThatVar as Long

    ' Code here to implement DoSomething...

    Exit Function

Handler:
    Err.Raise Err.Number, , "MiscFunctions.DoSomething: " & Err.Description

End Function

Quando hai chiamate nidificate, questo si svolge mentre ogni routine colpisce il suo gestore e aggiunge il suo nome alla descrizione dell'errore. Alla funzione di livello superiore, ottieni uno "stack di chiamate" mostrando l'elenco delle routine chiamate e il numero di errore e la descrizione dell'errore che si è effettivamente verificato. Non è perfetto, in quanto non ottieni numeri di riga, ma ho scoperto che di solito non hai bisogno di loro per trovare la strada per il problema. (E se vuoi davvero i numeri di riga, puoi inserirli nella funzione e fare riferimento a loro nell'istruzione Err.Raise usando la variabile Erl. Senza numeri di riga, restituisce solo 0.)

Inoltre, tieni presente che all'interno della funzione stessa puoi aumentare i tuoi errori con i valori di variabili interessanti nel messaggio in questo modo:

Err.Raise PCLOADLETTER_ERRNUM, , "PC Load Letter error on Printer """ & PrinterName & """"

(L'evidenziazione della sintassi appare traballante nell'anteprima ... Mi chiedo come apparirà una volta pubblicato?)

Answer 3

Il modo duro e manuale è praticamente l'unico modo. Se dai un'occhiata alla questa domanda, qualcuno ha suggerito uno strumento chiamato MZTools che farà gran parte del lavoro grugnito per te.

Answer 4

Come hanno detto altre persone (anni fa, vedo ... ma ci sono così tante persone che usano ancora VB6! :)), penso che non sia possibile recuperare a livello di codice lo stack di chiamate, a meno che non si utilizzi uno strumento di terze parti.

Ma se hai bisogno di farlo per scopi di debug, puoi considerare di aggiungere alla routine chiamata una variabile stringa di input opzionale, se inserirai il nome del chiamante.

Sub MyRoutine
    (...)  ' Your code here
    call DoSomething (Var1, Var2, Var3, "MyRoutine")
    '                                       ^
    '     Present routine's name -----------+

    (...)  ' Your code here

End Sub


Public DoSomething (DoVar1, DoVar2, DoVar3, Optional Caller as string = "[unknown]")
    Debug.Print " DoSomething Routine Called. Caller = " & Caller

    ... ' (your code here)

End Sub

Forse non così elegante, ma ha funzionato per me.

Saluti, Max - Italia

Answer 5

Compuware (o era Numega al momento) DevStudio per Visual Basic 6 era solito farlo. Il modo era di aggiungere l'aggiunta di strumentazione a ogni chiamata che chiamava un frammento molto piccolo aggiunto allo stack di codice. Su qualsiasi errore ha scaricato quel callstack e quindi ha fatto cose come la posta o inviare a un server web tutte le informazioni di debug. L'aggiunta e la rimozione della strumentazione è stata un'operazione potenzialmente letale (specialmente allora, quando utilizzavamo VSS come controllo del codice sorgente), ma se funzionava, funzionava bene.

Come Darrel ha sottolineato , puoi aggiungere qualcosa di molto semplice usando MZTools e impostando un modello. Funziona molto ed è probabilmente più efficace di quanto sarebbe la ricompensa, ma se hai difficoltà a rintracciare i bug, potrebbe essere d'aiuto).