excel - power - Errores planteados dentro de la depuración de clases como si se plantearan en una llamada de propiedad
power view error oleobject (4)
Esta "característica" es la misma en Excel 2003 y me sorprendería que sea diferente en 2007.
Estoy (lamentablemente) desarrollando una aplicación en Excel 2000 VBA. Creo que descubrí que cualquier error generado en una propiedad, función o sub errores de clase personalizada, como si el error se hubiera planteado en el punto en el código de VBA donde se llama a la propiedad. Es decir, el depurador VBE no me lleva al punto en la propiedad Class donde se produjo el error, sino en el lugar donde se ingresó la propiedad (desde un Módulo Sub o Función, por ejemplo) Esto hace que sea frustrante desarrollar algo más que el el código OO Excel 2000 VBA más superficial ya que tengo que pasar línea por línea a través de cada método de clase para descubrir las instrucciones que causan un error.
¿Me estoy perdiendo algo o se trata de un error conocido con el que tengo que lidiar en Excel 2000? ¿Se ha solucionado esto en 2003 o 2007?
Código de ejemplo:
''''''''''''''''''''''''''''''
''In Module1:
Public Sub TestSub1()
Dim testClass As Class1
Dim testVariant As Variant
Set testClass = New Class1
testVariant = testClass.Property1 ''Debugger takes me here...
End Sub
''''''''''''''''''''''''''''
'' In Class1
Property Get Property1() As Variant
Err.Raise 666, , "Excel 2000 VBA Sux!" ''But error is actually thrown here.
End Property
Esta página es un recurso muy bueno sobre el manejo de errores en VBA:
Para Office 2003, obtendrá este comportamiento cuando el depurador esté configurado para interrumpir los errores no controlados (la configuración predeterminada).
Si desea que se rompa en la línea Err.Raise, debe configurarla para romper todos los errores (Herramientas / Opciones / General / Trampa de errores / Interrumpir todos los errores).
Creo que es lo mismo para Office 2000 pero no tengo una copia para verificar.
Lo mismo sigue siendo cierto en Excel 2010: ahí es donde conocí este comportamiento.
Para citar el sitio de Chip Pearson :
No hay absolutamente ninguna razón para utilizar un ajuste de captura de errores que no sea Break In Class Module.
Su descripción de la diferencia entre los modos de error:
Cuando está probando y ejecutando su código, tiene tres modos de captura de errores. El primero es Romper todos los errores. Esto hará que el depurador se abra si ocurre algún error, independientemente de cualquier manipulación de errores que pueda tener en el código. La segunda opción es Romper en errores no controlados. Esto hará que el depurador se abra si la directiva On Error existente no maneja el error. Esta es la opción más utilizada y es la configuración predeterminada. La tercera opción, Break In Class Module es la más importante y la menos utilizada. No es el modo de captura de errores predeterminado, por lo que debe configurarlo manualmente.
El Módulo Break In Class es el más importante porque hará que el depurador rompa la línea de código dentro de un módulo de objeto que realmente está causando el problema. La configuración del Módulo Break in Class está en el cuadro de diálogo Opciones accesible en el menú Herramientas. Está en la pestaña General del cuadro de diálogo Opciones, como se muestra a continuación.