Introducci�n
-------------
Cuando se crean aplicaciones peque�as, es decir para pocos usuarios
(hasta podria ser solo una estaci�n), generalmente se omiten muchas
validaciones que m�s tarde se transforman en errores permanentes, a
estos errores se les conoce como errores latentes.
Debemos controlar debidamente los errores que se puedan producir en
nuestra aplicaci�n, incluso aquellos errores que no son directamente
de nuestra programaci�n (por ejemplo un error de conexi�n de red,
la caida del servicio de servidor SQL, etc), esto hara que nuestra
aplicaci�n permanesca siempre al frente y no se caiga en cualquier
momento, ya que creo que es molesto tener que estar iniciando nuevamente
la aplicaci�n, cada ves que se produsca un error.
Mi idea principal es presentar un forma de manejar los errores de una
aplicaci�n en un ambiente de alta concurrencia, donde existen muchos
usuarios que ingresan datos y otros que consultan al mismo tiempo, en
donde al servidor no esta en la misma empresa y adem�s se conectan
varias redes locales (y cada una con bastantes usuarios utilizando la
aplicaci�n), a este nivel m�s de algun bloqueo o interbloqueo ocurre en
la base de datos y hay que estar bien parado para solventarlo.
Bueno, algunos dir�n: "si, hay muchos tutoriales relacionados con este
tema...bla, bla bla", pero puedo decir que lo que deseo presentar en
este papel no es solo un menajo de errores en visual basic, sino que
adem�s de los anterior sea potente y pueda implementarse de tal forma
que permita utilizarce en nuevas aplicaciones o por desarrollar.
Con lo referente a la implementaci�n el objetivo principal ser�a que los
errores puedan manejarse por varios programadores, sin tener problemas o
dudas al momento de controlar los errores, o que cada uno quiera
implementar sus propias rutinas de manejo de errores. El punto es tener
solo un procedimiento y que ahi se controlen todos los errores, haciendo
que la aplicacion se controle desde un punto y por varias desarroladores
de software.
Antes, una idea con un buen argumento
---------------------------------------
A todo lo anterior quiero sumar la idea (nose si de locos, pero tengo
mis argumentos) de poder saber los errores que ocurren en todo el sistema,
y dar la posibilidad de que los usuarios finales de la aplicaci�n puedan
cominicar los errores facilmente a el departamento de desarrollo, ya sea
a traves de un email o por telefono, etc. Incluso podr�a ser que el usuario
no haga nada, sino que el email se envie autom�ticamente.
Problemas de performance por los emails no creo que hayan, ya que en una red
en donde existen bastantes usuarios, hay varias redes y todo lo dem�s, lo
m�s seguro es que detras hayan servidores, y por ah� m�s de alguno ser� de
correo. Si no lo hay o no se est� seguro de implementar por problemas de
rendimiento lo mejor es probar.
Todo lo anterior lo respaldo con que la aplicaci�n ya debe estar en su
estado de madures, cuando ya bastantes errores se han corregidos y a lo
mejor los que se presentan m�s son los relacionados con la concurrencia o
con problemas que no son del sistema en si, por ejemplo que se haya borrado
algun origen de datos, que se haya corrompido alguna libreria, etc.
----------------------------------------------------------------------------
NOTA:
Si hablamos de que nuestra aplicaci�n estar� sometida a un ambiente en donde
existe concurrecia lo mejor es utilizar procedimientos almacenados, tener
bien la relaciones, indices, etc (esto ya se da por sentado), podr�a decir
que estar constantemente buscando optimizar los procesos m�s complejos es
vital para mantener la aplicaci�n, ya que debemos de saber que siempre se
estar� agregando un usuario a la empresa, o se estar� agregando una nueva red
local (esto �ltimo puede producir una perdida de rendimiento bastante grande),
lo mejor es estar preparado y siempre velar por optimizar su aplicaci�n.
----------------------------------------------------------------------------
Una acercamiento a la implementaci�n
---------------------------------------
Cuando programamos una pantalla, por ejemplo una consulta de clientes y varios
de sus movimientos de dinero o compras, generalmente nos conectamos a la base de
datos y enviamos consultas sql o ejeuctamos un procedimiento almacenado, los
cuales nos devuelven un recordset o dataset en el caso de .NET (para el caso da
lo mismo) con los datos que vamos a procesar o mostrar en pantalla.
El principio del manejo de errores aqui sigue siendo el mismo, activar el manejador
de errores al principio y luego al final verificar los codigos de error y realizar
lo que se desee, por ejemplo
Sub Consulta()
On Error Goto CheckError
'
'conexiones al servidor de base de datos
'envio de consultas sql
'ejecucion de procedimientos almacenados
'etc...
'
CheckError:
If [Link] = 3021 Then
...
If [Link] = 6Then
...
End Sub
El c�digo anterior es lo t�pico, a veces en lugar de verificar los codigos de
erorres
se muestra un mensaje con el codigo de error, el origen y el mensaje. El tema es
que
el gran cambio que hay que hacer es solamente cambiar las condiciones con una
llamada
a un procedimiento y pasarle como parametro los datos del error, para luego
procesarlos
dentro del procedimiento. Otro dato que se puede pasar como parametro es el nombre
de la pantalla o procedimiento, o alguna descipci�n que indique de donde proviene
el
error, es decir el proceso que produjo el error. Entonces la rutina anterior
quedar�a:
Sub Consulta()
On Error Goto CheckError
'
'conexiones al servidor de base de datos
'envio de consultas sql
'ejecucion de procedimientos almacenados
'etc...
'
CheckError:
ErrorHandle('ProcesoDeError', [Link], [Link], [Link])
End Sub
Hasta este punto sabemos que si ocurre un error en las instrucciones debajo de On
Error
Goto, se saltar� a CheckError y se verificar�n los errores. A este punto ya nuestra
aplicaci�n no se cae, a menos que estemos controlando mal los errores. Los errores
tipicos que podemos controlar aqui son de conexi�n a la base de datos, el origen de
datos, problemas de red, al ejecutar MoveFirst cuando no hayan datos que procesar,
bloqueos e interbloqueos, etc. Nuestra aplicaci�n estar� m�s estable.
Cuando colocamos este manejador de error podemos controlar todos los tipos de
errores,
incluso los que ocurren en otro lugar, por ejemplo en un procedimiento almacenado.
Es importante mencionar que cuando llamamos a un procedimiento almacenado, el cual
puede tener varias instrucciones sql, tambien puede generar algun error que no
estemos
controlando dentro del mismo, en este caso el error o m�s bien los datos del error
se
devulven al manejador de errores de visual basic, con lo cual tambien los podremos
controlar, pero aqui los datos ser�n difirentes, por ejemplo el c�digo de error ya
no
es tan peque�o como el c�difo que entrega visual basic.
Podemos ver la diferencia de los errores:
Si el error ocurre dentro del c�digo de visual basic, los datos del error son de
visual basic.
Cuando realizamos un MoveFirst en un recordset que no tiene datos se produce el
error 3021, esto ya sea el resultado de una llamada a un procedimiento almacenado
o enviando la instruccion SQL:
On Error Goto CheckError
...
...
[Link] = "ConsultaCliente"
[Link](1) = ID_Cliente
Set dbRecordset [Link]
[Link] '->aqui ocurre el error si no hay datos que procesar
Cuando ejecutamos un procedimiento almacenado y dentro del mismo se intenta
insertar
un registro en un tabla con una clave que ya existe, nos devuelve el error -
2147217873,
bueno un poquito grande, por esta razon si vamos a colocar el codigo del error en
una
variable lo mejor es que esta sea de tipo Long.
On Error Goto CheckError
...
...
[Link] = "InsertIncorrecto"
[Link](1) = ID_Cliente
Set dbRecordset [Link] '->aqui ocurre el error, dentro del
procedimiento
[Link]
Como punto fina aqui, lo importante es que la implemtacion del manejador de errores
se
coloque en la mayoria de los procedimientos en visual basic, sobre todos los que
sean m�s
conplejos. Solo hay que activar el manejador y al final llamar a un procedimiento
(el que
maenjar� los errores).
