Cuando se produce un error en una función, me gustaría saber la secuencia de eventos que conducen a ella, especialmente cuando se llama a esa función desde una docena de lugares diferentes. ¿Hay alguna manera de recuperar la pila de llamadas en VB6, o tengo que hacerlo de la manera difícil (por ejemplo, entradas de registro en cada función y controlador de errores, etc.)?¿Es posible recuperar la pila de llamadas mediante programación en VB6?
Estoy bastante seguro de que tienes que hacerlo de la manera difícil. En un trabajo previo mío, tuvimos un proceso de manejo de errores muy elegante para VB6 con componentes DCOM. Sin embargo, fue necesario agregar un código redundante a cada método, tanto que teníamos herramientas propias para insertarlo todo para usted.
No puedo proporcionarle demasiada información sobre su implementación (porque me olvidé de la mayoría y existe la posibilidad de que lo consideren un secreto comercial). Una cosa que se destaca es que el nombre del método no se pudo derivar en 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 generarían errores que mintieron. ..).
HTH
La forma más dura, más o menos manual es la única manera. Si consulta la pregunta this, alguien sugirió una herramienta llamada MZTools que hará mucho del trabajo duro para usted.
He estado usando MZTools durante años y estoy de acuerdo en que es una gran herramienta. Sin embargo, estaba buscando una alternativa al "rastro de la pila del pobre". No pensé que hubiera ninguno, pero pensé que no estaría de más preguntarlo aquí. – raven
Compuware (o era Numega en ese momento) DevStudio para Visual Basic 6 solía hacer esto. El camino estaba añadiendo agregar instrumentación a cada llamada que llamara un fragmento muy pequeño que se agregó a la pila de códigos. En cualquier error, descartó 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 eliminar la instrumentación era una operación potencialmente letal (especialmente en aquel entonces, cuando usábamos VSS como nuestro control de origen), pero si funcionaba, funcionaba bien.
Como Darrel pointed out, podría agregar algo muy similar al usar MZTools y configurar una plantilla. Trabaja mucho, y probablemente sea más eficaz de lo que sería la recompensa, pero si tiene dificultades para localizar errores, podría ser útil).
Usted tiene que hacerlo de la manera más difícil, pero no es realmente todo lo que dura ... En serio, una vez que usted ha escrito la plantilla una vez, que es una copia rápida/pegar/Modificar para que coincida con el nombre de la función en la declaración Err.Raise al 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, 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" que muestra 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 generalmente no los necesitas para encontrar el camino al problema. (Y si realmente desea los números de línea, puede ponerlos en la función y hacer referencia a ellos en la instrucción Err.Raise utilizando la variable Erl. Sin números de línea, eso simplemente devuelve 0.)
Además, tenga en cuenta que función en sí, puede aumentar sus propios errores con los valores de las variables de interés en el mensaje de este modo:
Err.Raise PCLOADLETTER_ERRNUM, , "PC Load Letter error on Printer """ & PrinterName & """"
(el resaltado de sintaxis parece poco firme en la vista previa ... me pregunto cómo se va a ver cuando se publiquen?)
upvoted para la letra de la carga de la PC – rpetrich
Como dijeron otras personas (hace años, ya veo ... ¡pero hay tantas personas que todavía usan VB6! :)), creo que no es posible programar Recuperar ammáticamente la Pila de llamadas, a menos que use alguna herramienta de terceros.
Pero si necesita hacer eso para fines de depuración, puede considerar añadir a la rutina llamada una variable de cadena de entrada opcional, donde pondría 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
No tan elegante, tal vez, pero funcionó para mí.
Saludos, Max - Italia
¿Quién dijo alguna vez que VB6 era elegante de todos modos? – RubberDuck
esta es la única forma que conozco para hacerlo. Como se sugiere a continuación, MZTools puede ayudar. En su plantilla para su manejador de errores, si va a propagar el error, agregue su función/sub actual al err.source. –
Estoy convencido de que no hay forma de hacer lo que solicité, así que aceptaré esta respuesta. – raven