En Excel VBA, ¿es una buena práctica dejar las instrucciones Debug.Print en el código que entra en "producción"? Eso es bastante útil para depurar las hojas en tiempo real en la máquina del usuario cuando algo sale mal. ¿Afecta el rendimiento cuando Visual Studio está cerrado? Si no, ¿qué aconsejarías?¿Es una buena práctica dejar las instrucciones "Debug.Print" en el código que va en "producción"?
Debug.Print instrucción DO tiene un pequeño costo de rendimiento. Así que los evitaría en bucles que se ejecutan un billón de veces. Excepto por esos casos, creo que está bien guardarlos.
También podría usar directivas de compilación condicional (#if) en combinación con una constante de compilación (#const) para habilitarlas/deshabilitarlas globalmente sin afectar el rendimiento.
#CONST developMode = True
sub Xyz
#If developMode Then
Debug.Print "something"
#End If
End Sub
@iDevelop +1 Aprender algo nuevo todos los días - ¡no me di cuenta de la compilación condicional soportada por Excel! Gracias. – dash
que parece interesante, gracias! – Jerome
lo suficientemente claro para merecer un +1 :). Por cierto, la compilación condicional (y algunas otras cosas útiles) se discutió en este interesante hilo: http://stackoverflow.com/questions/1070863/hidden-features-of-vba – JMax
Normalmente tengo dos versiones; prod sin depuración, y prod con la depuración. Eso, combinado con el registro del gestor de errores catchall, significa que si un usuario tiene problemas, puedo implementar la versión de depuración y pueden ejecutarlo.
Tengo una macro que corro que comenta los enunciados de debug.print, por lo que no es una sobrecarga de mantenimiento real.
El problema con ejecutar una versión de depuración todo el tiempo (y, con Excel VBA no suele ser una cuestión de rendimiento) es que su aplicación está emitiendo constantemente información que no necesita también. En un entorno con hojas de cálculo controladas, por ejemplo, esto puede verse como algo malo.
En términos de manejo de errores global, sigue siendo necesario el error comunicado en Ir para cada función que se desea el control de errores en Puede, sin embargo, el tubo de éstos a una función común:.
Public Function HandleTheNastyErrors(E As ErrObject, ByVal writeLog As Boolean = True)
Select Case E.Number
Case xxx
...specific error handling...
Case Else
... Display a message to the user about how you dont know what happened....
End Select
If writeLog Then
...Log Writing Code...
End If
End Function
Y luego, OnError:
ErrorHandler:
Call HandleTheNastyErrors(Err, True)
Mostrar el truco
¿Podría comentar sobre su "capturar todo"? Realmente no tengo ideas de cómo manejar los errores de manera inteligente y de alguna manera genérica hasta ahora. Gracias ! – Jerome
@jeromeG Ahí tienes. Espero eso ayude. – dash
pasando el objeto de error a la función ... esa es una idea interesante. –
usted dice "Visual Studio", pero se habla de VBA, ¿verdad? ¿Te refieres a VBE? – aevanko
Ahhh, sí, supongo que entiendo lo que las personas llaman VBE ahora ... Sí, supongo que sí :) [ALT + F11] – Jerome
1) Si es importante capturar lo que el usuario estaba haciendo cuando las cosas salieron mal, un registro de transacciones sería una mejor opción. Comience un nuevo archivo por ejecución o por día; eliminar cualquiera de más de 48 horas de antigüedad. Sí, hay un costo de rendimiento, pero ¿cómo lo medirías? 2) Visual Studio es el entorno de desarrollo de MS para sus idiomas profesionales. VB 2010 es cientos de veces más rápido que VBA/VBE y tiene miles de instalaciones geniales. Puede acceder a Excel desde allí si desea usar una hoja de trabajo. –