Número máximo de Err.Raise?

Question

¿Por qué cuando uso Err.Raise 65536 el Err.Number tendrá realmente el valor de 5 y no 65536?

Según Raise definición: Sub Raise(Number As Long, [Source], [Description], [HelpFile], [HelpContext]). El parámetro que pasa es Long y Err.Number es también Long.

¿Por qué no puedo usar valores superiores a 65535?

Private Sub Command1_Click() 
Dim a As Long 
    On Error GoTo ErrCatch 
    For a = 0 To 99999 
     Err.Raise a 
     DoEvents 
    Next a 
    Exit Sub 
ErrCatch: 
    ' this is where Err.Number is evaluated 
    Resume Next 
End Sub` 

Answer 1

a partir del número MSDN documentation:

requeridos. Número entero largo que identifica la naturaleza del error. Los errores de Visual Basic están en el rango 0-65535; el rango 0-512 está reservado para errores del sistema; el rango 513-65535 está disponible para los errores definidos por el usuario. Al establecer la propiedad Number en su propio código de error en un módulo de clase, agrega su número de código de error a la constante vbObjectError. Por ejemplo, para generar el error número 513, asigne vbObjectError + 513 a la propiedad Number.

Así que, aunque se puede presentar un valor mayor que 65535, 65535 nada más grande que se convertirá en un error 5.

Answer 2

de error 5 es

Run-Time Error '5': Invalid Procedure Call or Argument” 

Junto con Justins contestar esto tendría sentido. La función Aumentar arroja el error 5 cuando lo llama con un número entero mayor a 65535 porque es un argumento no válido.

¿Puede mostrar algún código y puedo ayudarlo un poco mejor?

Answer 3

Aunque Number se especifica como un Long, en la documentación de Err.Raise dice que sólo los valores 0 -65535 son válidos. Por lo tanto, el error que está viendo es en realidad porque está violando las restricciones en Err.Raise.

Por qué no lo hicieron un Integer es un misterio (quizás en caso de que el rango válido se expanda en el futuro).

Answer 4

Existe un nivel más allá de "Microsoft lo dijo". El número de error que genera es un entero de 32 bits porque es parte de la especificación COM para pasar errores entre componentes. Todos los métodos públicos de un componente son en realidad funciones que devuelven HRESULT como valor de retorno; si tiene una función VB, mapea secretamente el valor de retorno de la función a un parámetro [out]. el valor de HRESULT es un campo de bits compuesto por una gran cantidad de valores, pero para mantener las cosas simples, puede dividirlo en dos porciones de 16 bits. Los 16 bits más bajos contienen el número de error real, que está entre 0 y 65535, el rango de 16 bits sin signo. Hay muchos estándares para los 16 bits superiores. El más importante es 0x0000. Todas las constantes que usan esto comienzan con "S_" (significa éxito). El valor de 32 bits más utilizado es S_OK (0x00000000). Si se devuelve este valor, entonces la función ha tenido éxito. La mayoría de sus llamadas al método VB devolverá este valor. Sin embargo, cualquier valor cuyo bit superior esté configurado indica que ha habido un error. En hexadecimal, estos son valores que parecen 0x8___. Hay muchas clases de error. El que VB devuelve por defecto es 0x800A.Sin embargo, la especificación COM solo le ofrece una clase que puede usar oficialmente, 0x8004, que se representa en VB como la constante vbObjectError.

De hecho, VB recomienda usar la constante vbObjectError al generar errores en los métodos públicos en archivos DLL o EXEs de ActiveX. Si lo haces o no hace ninguna diferencia. Simplemente significa que el error que recibe el código de llamada es muy grande y negativo, por lo que debe AND su número de error con & H0000FFFF. Curiosamente, también recomienda que no haga haciendo esto con los métodos de control ActiveX, por alguna razón. Aún más interesante, VB sí mismo ANDs todos los números de error con 0x800A0000 cuando los elevas por defecto, y también detecta si un número de error contiene 0x800A_ _ - y si es así, quita los 16 bits superiores para ti, de todos modos, solo tratas con el número de error en sí. En mi lugar de trabajo, el estándar es ignorar vbObjectError para aprovechar este comportamiento.

Me pregunto si alguien ha tenido todos los problemas al no usar vbObjectError. Ciertamente no tenemos