Pregunta

Cuando se produce un error en una función, me gustaría saber la secuencia de eventos que llevan a ella, especialmente cuando se llama a esa función desde una docena de lugares diferentes. ¿Hay alguna forma de recuperar la pila de llamadas en VB6, o tengo que hacerlo de la manera más difícil (por ejemplo, entradas de registro en cada función y controlador de errores, etc.)?

¿Fue útil?

Solución

Estoy bastante seguro de que tienes que hacerlo de la manera más difícil. En un trabajo mío anterior, tuvimos un proceso de manejo de errores muy elegante para VB6 con componentes DCOM. Sin embargo, era mucho el código redundante que debía agregarse a cada método, tanto que teníamos herramientas propias para insertarlo todo por usted.

No puedo proporcionar demasiada información sobre su implementación (porque he olvidado la mayoría y existe la posibilidad de que lo consideren un secreto comercial). Una cosa que sí se destaca es que el nombre del método no se pudo derivar en el tiempo de ejecución, por lo que se agregó como una variable de cadena (algunos desarrolladores copiarían y pegarían en lugar de usar la herramienta y conducirían a pilas de errores que mentían). ..).

HTH

Otros consejos

Tienes que hacerlo de la manera más difícil, pero en realidad no es todo that difícil ... En serio, una vez que has escrito la plantilla una vez, es un copie / pegue / modifique rápidamente para que coincida con el nombre de la función en la declaración Err.Raise con el nombre de la función 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

Cuando tiene llamadas anidadas, esto se desenrolla cuando cada rutina golpea su Controlador y agrega su nombre a la descripción del error. En la función de nivel superior, obtienes una " pila de llamadas " mostrando la lista de rutinas que fueron llamadas, y el número de error y la descripción del error que realmente ocurrió. No es perfecto, ya que no obtienes números de línea, pero he descubierto que normalmente no los necesitas para encontrar el camino hacia el problema. (Y si realmente quieres números de línea, puedes ponerlos en la función y hacer referencia a ellos en la declaración Err.Raise usando la variable Erl. Sin números de línea, eso solo devuelve 0).

Además, tenga en cuenta que dentro de la función en sí misma, puede generar sus propios errores con los valores de las variables interesantes en el mensaje, de este modo:

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

(El resaltado de sintaxis se ve borroso en la vista previa ... Me pregunto cómo se verá cuando se publique)

La forma dura y manual es prácticamente la única. Si consulta esta pregunta, alguien sugirió una herramienta llamada MZTools que hará mucho del trabajo duro por ti.

Como dijeron otras personas (hace años, veo ... pero hay mucha gente que todavía usa VB6! :)), creo que no es posible recuperar la Pila de llamadas mediante programación, a menos que use alguna herramienta de terceros.

Pero si necesita hacer eso para propósitos de depuración, puede considerar agregar a la rutina llamada una variable de cadena de entrada opcional, donde colocará el nombre de la persona que llama.

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

Tal vez no sea tan elegante, pero funcionó para mí.

Saludos, Max - Italia

Compuware (o era Numega en ese momento) DevStudio para Visual Basic 6 solía hacer esto. La forma era agregar agregando instrumentos a cada llamada que llamaba un fragmento muy pequeño que se agregaba a la pila de códigos. En cualquier error, descargó esa pila de llamadas y luego hizo cosas como enviar por correo o publicar en un servidor web toda la información de depuración. Agregar y quitar la instrumentación fue una operación potencialmente letal (especialmente cuando estábamos usando VSS como nuestro control de origen), pero si funcionó, funcionó bien.

Como señaló Darrel , puedes agregar algo muy simple usando MZTools y configurando una plantilla. Es mucho trabajo, y es probablemente más efímero de lo que sería la recompensa, pero si tiene problemas para rastrear errores, puede ser útil).

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top