clase error

"Hugo Gsell" escribió en el mensaje
news:
Mostrar la cita

una pregunta mas haber digamos que uso dos capas .. presentación y
accesoadatos

En acceso a datos hace algo como

Grabaregistro(parametros a grabar)
abrebase
abretabla
grabadatos
dispose
Finaccesoadatos

ahora bien para que el cath funcione en la capa llamadora.
debo NO PONER CONTROL DE TRY ... CATH en Grabaregistro... supongamos que
ocurre un error al conectarse a la base de datos
Si pongo el control lo captura allá y en mi clicengrabar ni me entero..
ahora si no pongo el control ocurre el error y la captura se trasala al
clcengrabar
¿ESTO ES LO QUE ESTAS PLANTEANDO?
¿CREES QUE ESTÁ BIEN HACERLO ASÍ?

Hola.

Me parece tan bien que es como lo hago normalmente :-)

Trabajo mucho con el concepto de separacion Vista-Controlador-Modelo. La
"vista" equivale a la capa de presentación del modelo ortodoxo; en el
"modelo" están las entidades del dominio (comunes a todo un universo de
aplicaciones: clientes, cuentas, bancos, productos, interfaces genericas
como documentos comerciales, entidades, personas, etc) y las entidades de
aplicacion (generalmente derivadas de las interfaces genericas del dominio).
Y en los controladores se implementan las interacciones entre estas
entidades para la ejecución de las operaciones. La lógica y las politicas
del negocio afectan primordialmente estas operaciones. Las operaciones de
acceso a datos forman parte de cada entidad.

En los controladores es donde se ejecutan todos los procesos no atómicos
(como la creación de un cliente o la actualizacion de los datos de un
producto).

Un ejemplo de controlador podria ser asi:

Try
Dim cmd As Command = AppEnvironment.GetCommand()
Factura.StartProcess(cmd)
For Each Det As DetalleFactura In Detalles
Factura.AddDetalle(Det, cmd)
Next
Factura.EndProcess(cmd)
cmd.Transaction.Commit()
Catch ex As Exception
Factura.Reset()
cmd.Transaction.Rollback()
errHandler.Handle(ex)
Finally
cmd.Dispose()
End Try

Pero hay errores "recuperables" que tambien disparan excepciones, y que es
mejor manejar localmente.

Por ejemplo, vas a actulizar un registro que ha sido modificado dentro de
una transacción larga, y todos los mecanismos de reintento intrinseco
expiran. Supongamos que existe la funcion ErrorBloqueo(ex As Exception) que
devuelve True si la excepcion corresponde a un error de bloqueo y False si
su causa es cualquier otra.
Si vas a realizar una actualizacion, podrias escribir:

Errores = 0
Do
Try
cmd.ExecuteNonQuery()
Errores = 0
Catch ex As Exception
If ErrorBloqueo(ex) Then
Errores += 1
If Errores > MAX_INTENTO Then
Throw New Exception("Error de bloqueo", ex)
End If
End If
End Try
Loop While Errores

En el bloque Try..Catch tratas de resolver el problema. Si despues de
intentarlo una cantidad razonable de veces no lo logras, tiras la excepcion
hacia arriba.

Realmente no se si esta sea la mejor manera de manejar los errores. Es
simple, segura, y hasta ahora me ha funcionado.


Salud!

"Leonardo Azpurua [mvp vb]" <l e o n a r d o (arroba) m v p s (punto) o r g>
escribió en el mensaje news:
Mostrar la cita

Si vas a realizar una actualizacion, podrias escribir:

Errores = 0
Do
Try
cmd.ExecuteNonQuery()
Errores = 0
Catch ex As Exception
If ErrorBloqueo(ex) Then
Errores += 1
If Errores > MAX_INTENTO Then
Throw New Exception("Error de bloqueo", ex)
End If
End If
End Try
Loop While Errores

Hay un error. Lo correcto sería:

Do
Try
cmd.ExecuteNonQuery()
Errores = 0
Catch ex As Exception
If ErrorBloqueo(ex) Then
Errores += 1
If Errores > MAX_INTENTO Then
Throw New Exception("Error de bloqueo", ex)
End If
Else
Throw
End If
End Try
Loop While Errores

Salud!