Est-il possible de récupérer la pile d'appels par programme dans VB6?

Question

Lorsqu’une erreur survient dans une fonction, j'aimerais connaître la séquence des événements qui y mènent, en particulier lorsque cette fonction est appelée depuis une douzaine d’endroits différents. Existe-t-il un moyen de récupérer la pile d'appels dans VB6 ou dois-je le faire de manière difficile (par exemple, enregistrez les entrées dans chaque fonction et chaque gestionnaire d'erreurs, etc.)?

Answer 1

Je suis sûr que vous devez le faire à la dure. Dans un de mes emplois précédents, nous avions un processus de traitement des erreurs très élégant pour VB6 avec composants DCOM. Cependant, c’était beaucoup de code redondant qui devait être ajouté à chaque méthode, à tel point que nous avions des outils développés localement pour tout insérer pour vous.

Je ne peux pas vous donner trop d'informations sur sa mise en œuvre (à la fois parce que j'ai presque tout oublié et qu'il est possible qu'ils considèrent cela comme un secret commercial). Une chose qui se démarque est que le nom de la méthode ne pouvait pas être dérivé au moment de l’exécution, il a donc été ajouté en tant que variable chaîne (certains développeurs copient-collent au lieu d’utiliser l’outil, ce qui donnerait lieu à des piles d’erreurs. ..).

HTH

Answer 2

Vous devez le faire à la dure, mais ce n'est pas vraiment aussi difficile ... Sérieusement, une fois que vous avez écrit le modèle, c'est un copier / coller / modifier rapidement pour faire correspondre le nom de la fonction dans l’instruction Err.Raise au nom de la fonction réelle.

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

Lorsque vous avez des appels imbriqués, cela se résorbe lorsque chaque routine atteint son gestionnaire et ajoute son nom à la description de l'erreur. Au niveau supérieur, vous obtenez une "pile d’appels". affichant la liste des routines appelées, ainsi que le numéro et la description de l'erreur réellement survenue. Ce n'est pas parfait, car vous n'obtenez pas les numéros de ligne, mais j'ai constaté que vous n'en avez généralement pas besoin pour trouver votre chemin vers le problème. (Et si vous voulez vraiment des numéros de ligne, vous pouvez les insérer dans la fonction et les référencer dans l’instruction Err.Raise à l’aide de la variable Erl. Sans les numéros de ligne, cela ne renvoie que 0.)

Notez également que dans la fonction elle-même, vous pouvez générer vos propres erreurs avec les valeurs des variables intéressantes dans le message, comme suit:

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

(La mise en évidence de la syntaxe n'a pas l'air géniale dans l'aperçu ... Je me demande comment ça va paraître une fois posté?)

Answer 3

Le moyen manuel et dur est à peu près le seul moyen. Si vous consultez la question , quelqu'un suggéré un outil appelé MZTools qui fera une grande partie du travail difficile pour vous.

Answer 4

Comme d'autres personnes l'ont dit (il y a des années, je vois ... mais il y a tellement de gens qui utilisent encore VB6! :)), je pense qu'il n'est pas possible de récupérer par programme la pile d'appels, à moins d'utiliser un outil tiers.

Mais si vous avez besoin de le faire à des fins de débogage, vous pouvez ajouter à la routine appelée une variable Chaîne d'entrée facultative, à condition d'indiquer le nom de l'appelant.

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

Pas si élégant, peut-être, mais ça a fonctionné pour moi.

Cordialement, Max - Italie

Answer 5

Compuware (ou était-ce Numega à l’époque) utilisé auparavant par DevStudio pour Visual Basic 6. Pour ce faire, vous ajoutiez de l'instrumentation à chaque appel appelé un très petit extrait ajouté à la pile de code. En cas d'erreur, il vidait cette pile d'appels, puis envoyait toutes les informations de débogage à un courrier ou à une publication sur un serveur Web. L'ajout et le retrait de l'instrumentation étaient une opération potentiellement mortelle (surtout à l'époque, lorsque nous utilisions VSS comme contrôle de source), mais si cela fonctionnait, cela fonctionnait bien.

As Darrel a souligné <, vous pouvez ajouter quelque chose de très similaire en utilisant MZTools et en configurant un modèle. C'est beaucoup de travail, et c'est probablement plus d'effort que la récompense serait, mais si vous avez très difficile à traquer les bugs, cela pourrait aider).