Pregunta de debugger

[proteo1]

Hola a todos, estoy realizando un metodo de registro utilizando divisiones entre 0 (cero), esto para atrapar el desbordamiento lo cual se logra al realizar una comparacion de valores, y el metodo analiza todo y si los datos son correctos divide entre cero sino continua normal.

Mi pregunta es saber que es lo que hace un debugger cuando detecta esto?

vb6 Ejemplo:

Option Explicit

Private Function Registro()
 On Error GoTo Mal
 Dim Resultado As Integer
 Dim Ciclo As Integer
 For Ciclo = Len(Text1.Text) To Len(Text1.Text) * 2
  'Bla bla bla ;)
 End If
 Resultado = Int(Ciclo / 0)'Cero por poner una constante solamente
 
Mal:
 MsgBox "Validando el Text1, de nuevo :("
 'Validacion de la llave, si pasa o no, no manda ninguna alerta
 Exit function
End Function

Quiero utilizar las menos constantes posibles. asi como algunos comparadores IMP, EQV y XOR de Visual Basic 6

De antemano gracias por la informacion que puedan proporcionar.

[hystd]

Pues en ese caso cuando se hace la división por cero (un DIV en ensamblador), el procesador pone a 1 el bit Z de "división por cero" de su FPU (Floating Point Unit), en cuyo caso, bifurcará el flujo de ejecución hacia la rutina indicada por el vector de excepciones/interrupciones del sistema operativo. Para ello almacenará en la pila la dirección de retorno (actual puntero de instrucción) y lo asignará hacia la dirección indicada por el vector, para que dé comienzo la rutina de excepción.

Dicha rutina se ejecutará en modo kernel. Una vez ejecutada dicha rutina de atención de la excepción por parte del sistema operativo, devolverá el flujo de ejecución a donde se quedó antes de hacer el DIV, haciendo una llamada a zwContinue (también en modo kernel), la cual asignará el puntero de instrucción al valor almacenado anteriormente en la pila.

Al volver al flujo de ejecución, si tu aplicación no captura la excepción, el ciclo se repetirá una y otra vez, hasta que el sistema operativo le dé por abortar el proceso... Si por el contrario, la aplicación captura la excepción, por ejemplo usando una estructura del tipo try - catch - finally, entonces el flujo de ejecución continuará por el catch hasta finalizar.

Un saludo.

[proteo1]

Pues en ese caso cuando se hace la división por cero (un DIV en ensamblador), el procesador pone a 1 el bit Z de "división por cero" de su FPU (Floating Point Unit), en cuyo caso, bifurcará el flujo de ejecución hacia la rutina indicada por el vector de excepciones/interrupciones del sistema operativo. Para ello almacenará en la pila la dirección de retorno (actual puntero de instrucción) y lo asignará hacia la dirección indicada por el vector, para que dé comienzo la rutina de excepción.

Dicha rutina se ejecutará en modo kernel. Una vez ejecutada dicha rutina de atención de la excepción por parte del sistema operativo, devolverá el flujo de ejecución a donde se quedó antes de hacer el DIV, haciendo una llamada a zwContinue (también en modo kernel), la cual asignará el puntero de instrucción al valor almacenado anteriormente en la pila.

Al volver al flujo de ejecución, si tu aplicación no captura la excepción, el ciclo se repetirá una y otra vez, hasta que el sistema operativo le dé por abortar el proceso... Si por el contrario, la aplicación captura la excepción, por ejemplo usando una estructura del tipo try - catch - finally, entonces el flujo de ejecución continuará por el catch hasta finalizar.

Un saludo.

WOOOOW muchisimas gracias, maestro.

[proteo1]

Que opinan del contenido de este modulo

Option Explicit
Private Declare Function IsDebuggerPresent Lib "Kernel32" () As Long

Public Function IsDebuggerB() As Boolean
 IsDebuggerB = IsDebuggerPresent
End Function

Public Function IsDebuggerN() As Integer
 IsDebuggerN = IsDebuggerPresent
End Function

Segun yo mando directamente el resultado, en booleando o en numerico.

[Fruit]

Opino que si la implementación de esa función es:

BOOL WINAPI IsDebuggerPresent(void);

No tiene ningún sentido usar un int.

[hystd]

Totalmente de acuerdo con fruit en que un int no tiene ningún sentido... pero más bien, no tiene ningún sentido "semántico".

A ver, un BOOL es un booleano de 32 bits. Si miras el tamaño de un int, es de 32 bits también, por lo que el compilador no protestará (o no debería, salvo por la definición de la cabecera de la función). Visto así, se podría recoger el resultado en cualquier variable o puntero a un dato de 32 bits.

Más correctamente, si yo quisiera complicarme la vida usando enteros, emplearía un unsigned int para este caso, aunque como ya digo, son ganas de marear la perdiz, cuando puedes usar un BOOL como está estipulado.

Un saludo.