clase error

04/07/2006 - 13:23 por Hugo Gsell | Informe spam
Como me he cansado un poco de manipular los errores he decidido crear mi
propia clase de error.

Esto es, en las distintas capas, especialmente en las de acceso a datos y
negocio, se tendrán muchas funciones que devolverán un valor, o un conjunto
de valores. Este valor puede representar por ej. si se cumple alguna
condicion (de regla de negocio), o si un registro existe, o si se pudo
realizar la grabación de una transacción compleja (o no), etc, etc.
El tema es, que si se produce un error, una politica de acción sería por ej.
que la función nos devolviera falso y que el mensaje de error apareciera 'en
la capa donde se produjo el error'. Pero además sería interesante que la
capa llamadora pueda obtener alguna información adicional sobre el error
producido... aquí entra mi idea de 'crear un objeto' genérico que además
de la información solicitada a la funcion nos devolviera detalles del
problema producido, objeto del error, numero interno de error, tal ves un
nro propio de error, descripción del error, etc.
¿Alguien ha hecho algo de esto?
¿Los objetos existentes tienen alguna propiedad error ó algun mecanismo que
simule lo que propongo?
Esta pregunta viene a lo siguiente... por ejemplo si creo un procedure en
capa de datos que me devuelva un objeto DataTabla
Public sub RecuperoDatos as DataTable el objeto data table ¿no tiene
algun objeto errors o algo similar que pueda utilizar para 'meter' el error
que se produjo?


Hugo A. Gsell
Sgo del Estero
Argentina

Preguntas similare

Leer las respuestas

#1 Eduardo A. Morcillo [MS MVP VB]
04/07/2006 - 17:50 | Informe spam
Pero para eso están las excepciones!

Eduardo A. Morcillo [MS MVP VB]
http://www.mvps.org/emorcillo
http://mvp.support.microsoft.com/pr...Cán
Respuesta Responder a este mensaje
#2 Hugo Gsell
05/07/2006 - 13:36 | Informe spam
si... lo he analizado un poco mejor... y decidí que el error "real" se
muestre (msgbox o lo que sea) en la capa mas baja y chau... a los sumo
la función grabar devuelve un FALSE y listo
De todas formas gracias por 'leerme'
Un saludo

Hugo A. Gsell
Sgo del Estero
Argentina

"Eduardo A. Morcillo [MS MVP VB]" <emorcillo .AT. mvps.org> escribió en el
mensaje news:
Pero para eso están las excepciones!

Eduardo A. Morcillo [MS MVP VB]
http://www.mvps.org/emorcillo
http://mvp.support.microsoft.com/pr...Cán

Respuesta Responder a este mensaje
#3 Eduardo A. Morcillo [MS MVP VB]
05/07/2006 - 16:16 | Informe spam
si... lo he analizado un poco mejor... y decidí que el error "real" se
muestre (msgbox o lo que sea) en la capa mas baja



No me parece bien. El error si no se lo maneja deberia subir hasta la capa
de presentación y recien ahi mostrarse al usuario. Ahora puede ser que te
funcione bien haciendolo en la capa mas baja, pero si luego esta capa tiene
que correr en otra maquina o bajo una aplicacion web el msgbox ya no te
sirve.

Eduardo A. Morcillo [MS MVP VB]
http://www.mvps.org/emorcillo
http://mvp.support.microsoft.com/pr...4EF5A4191C
Respuesta Responder a este mensaje
#4 Leonardo Azpurua [mvp vb]
05/07/2006 - 16:38 | Informe spam
"Hugo Gsell" escribió en el mensaje
news:%
si... lo he analizado un poco mejor... y decidí que el error "real" se
muestre (msgbox o lo que sea) en la capa mas baja y chau... a los sumo
la función grabar devuelve un FALSE y listo
De todas formas gracias por 'leerme'
Un saludo



Hola, Hugo:

Si muestras el error en la capa mas baja y luego determinas el resultado en
función de un valor devuelto, ocurriran dos cosas:

1: Los componentes servidores no podran correr como procesos desatendidos.
Eso entorpecerá la reorganización de la aplicacion en componentes
distribuídos

2: Alguien llamará a la función sin evaluar el valor devuelto (cada vez mas
personas asumimos que si algo anda mal se generará una excepción), ignorará
un código de error y acabará produciendo un resultado inimaginable y
castrofico.

Igual los problemas no son tan evidentes ahora: tu aplicacion no parece
necesitar un entorno distribuido y solo la mantienes tu, que eres infalible
y jamás dejas de chequear los valores devueltos por las funciones.

Pero el futuro es impredecible. Igual aciertas y tu aplicacion comienza a
venderse como pan caliente y tienes que contratar ayuda. O bien te la compra
General Motors, y deciden que quieren que los componentes de soporte estén
en su servidor corporativo de Detroit (o te piden que desarrolles una
interfaz Web). Y en ese momento tienes que rehacer buena parte de la
aplicación o establecer y documentar unos estándares irracionales (no
confíen en las excepciones) y estrictos (para que nunca nadie olvide
verificar el valor devuelto por las funciones).

No es lo mismo darle un mateo a un procedimiento que determinar la manera en
que se comunicarán entre si los diferentes componentes funcionales.

Lo que estas tomando es una decisión "de arquitectura", es decir
fundamental. Y es una pésima decision.


Salud!
Respuesta Responder a este mensaje
#5 Leonardo Azpurua [mvp vb]
05/07/2006 - 16:38 | Informe spam
"Hugo Gsell" escribió en el mensaje
news:%
si... lo he analizado un poco mejor... y decidí que el error "real" se
muestre (msgbox o lo que sea) en la capa mas baja y chau... a los sumo
la función grabar devuelve un FALSE y listo
De todas formas gracias por 'leerme'
Un saludo



Hola, Hugo:

Si muestras el error en la capa mas baja y luego determinas el resultado en
función de un valor devuelto, ocurriran dos cosas:

1: Los componentes servidores no podran correr como procesos desatendidos.
Eso entorpecerá la reorganización de la aplicacion en componentes
distribuídos

2: Alguien llamará a la función sin evaluar el valor devuelto (cada vez mas
personas asumimos que si algo anda mal se generará una excepción), ignorará
un código de error y acabará produciendo un resultado inimaginable y
castrofico.

Igual los problemas no son tan evidentes ahora: tu aplicacion no parece
necesitar un entorno distribuido y solo la mantienes tu, que eres infalible
y jamás dejas de chequear los valores devueltos por las funciones.

Pero el futuro es impredecible. Igual aciertas y tu aplicacion comienza a
venderse como pan caliente y tienes que contratar ayuda. O bien te la compra
General Motors, y deciden que quieren que los componentes de soporte estén
en su servidor corporativo de Detroit (o te piden que desarrolles una
interfaz Web). Y en ese momento tienes que rehacer buena parte de la
aplicación o establecer y documentar unos estándares irracionales (no
confíen en las excepciones) y estrictos (para que nunca nadie olvide
verificar el valor devuelto por las funciones).

No es lo mismo darle un mateo a un procedimiento que determinar la manera en
que se comunicarán entre si los diferentes componentes funcionales.

Lo que estas tomando es una decisión "de arquitectura", es decir
fundamental. Y es una pésima decision.


Salud!
Respuesta Responder a este mensaje
Ads by Google
Help Hacer una preguntaSiguiente Respuesta Tengo una respuesta
Search Busqueda sugerida