É possível recuperar a chamada pilha de programação em VB6?

Question

Quando ocorre um erro em uma função, eu gostaria de saber a seqüência de eventos que levam até ele, especialmente quando essa função é chamada a partir de uma dúzia de lugares diferentes. Existe alguma maneira de recuperar a pilha de chamadas em VB6, ou eu tenho que fazer isso da maneira mais difícil (por exemplo, entradas de log em cada manipulador de função e erro, etc.)?

Answer 1

Eu tenho certeza que você tem que fazer isso da maneira mais difícil. Em um trabalho anterior da mina, tivemos um processo de tratamento de erro muito elegante para VB6 com componentes DCOM. No entanto, foi um código muito redundante que tinha de ser adicionado a todos os métodos, tanto que tínhamos ferramentas para inserir tudo para você home-grown.

Eu não posso fornecer muito discernimento sobre a sua execução (tanto porque esqueci a maior parte dele e há uma chance de que eles podem considerá-lo um segredo comercial). Uma coisa que se destaca é que o nome do método não pode ser derivada em tempo de execução por isso foi adicionado como uma variável de string (alguns desenvolvedores que copiar e colar em vez de usar a ferramenta e que levaria a pilhas de erro que mentiram. ..).

HTH

Answer 2

Você tem que fazê-lo da maneira mais difícil, mas não é realmente tudo o que difícil ... A sério, uma vez que você tenha escrito o modelo de uma vez, é uma cópia rápida / colar / modificar para coincidir com o nome da função na declaração Err.Raise para o nome da função real.

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 você tem chamadas aninhadas, este desenrola como cada rotina atinge seu Handler e adiciona seu nome para a descrição do erro. Na função de nível superior, você tem uma "pilha de chamadas", mostrando a lista de rotinas que foram chamados, e o número do erro e a descrição do erro que ocorreu realmente. Não é perfeito, em que você não obter números de linha, mas eu achei que você não costuma precisar deles para encontrar o seu caminho para o problema. (E se você realmente quer números de linha, você pode colocá-los na função e referenciá-los na declaração Err.Raise usando a variável Erl. Sem números de linha, que apenas retorna 0.)

Além disso, nota que, dentro da própria função, você pode aumentar seus próprios erros com os valores das variáveis ??interessantes na mensagem assim:

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

(A sintaxe destacando aparência vacilante na visualização ... Eu me pergunto como ele vai olhar quando postado?)

Answer 3

A maneira mais difícil, manual é praticamente o único caminho. Se você verificar esta questão , alguém sugeriu uma ferramenta chamada MZTools que vai fazer a maior parte do trabalho pesado para você.

Answer 4

Como outras pessoas disseram (anos atrás, eu ver ... mas há muitas pessoas que ainda usam VB6! :)), eu acho que não é possível recuperar programaticamente a pilha de chamadas, a menos que você use alguma ferramenta de 3rd-festa.

Mas se você precisa fazer isso para fins de depuração, você pode considerar de adicionar à rotina chamada uma variável de cadeia de entrada opcional, foram você vai colocar o nome da pessoa.

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

Não é tão elegante, talvez, mas ele trabalhou para mim.

Saudações, Max - Itália

Answer 5

Compuware (ou era NuMega na época) DevStudio para o Visual Basic 6 usado para fazer isso. O caminho estava adicionando adicionando instrumenation para cada chamada que chamou um pequeno trecho que acrescentou à pilha de código. Em qualquer erro despejou que callstack, e depois fez coisas como e-mail ou correio para um servidor web todas as informações do debuging. Adicionar e remover a instrumentação foi uma operação potencialmente letal (especialmente naquela época, quando estávamos usando VSS como o nosso controle de origem), mas se ele trabalhou, ele funciona bem.

Como Darrel apontou , você pode adicionar algo muito simlar usando MZTools ea criação de um modelo. É um monte de trabalho, e é provavelmente mais effeort do que a recompensa seria, mas se você tem muito difícil de rastrear erros, pode ajudar).