HANDLER EXCEPTION para registro

[oms02]

Hola a todos.

Vereis, tengo una duda con el manejo de errores (con excepciones) en un SP.

El asunto es que por lo que he podido ver por la red, MySQL no dispone actualmente de variables globales para poder capturar el código y mensaje del error. Si he buscado bien, cada HANDLER se maneja con un SQL STATE determinado. (El ideal que buscaba era capturar el código y realizar un INSERT en una tabla "log de errores").

El problema viene con lo siguiente:

Tengo hecho un SP que se encarga del proceso de registro. Me gustaría implementar los HANDLER en éste, ya que se trata de un proceso importante.

La duda está en que el listado de códigos de error es interminable y no se si muchos de ellos podrían producirse en el proceso de registro del usuario (principalmente compuesto de INSERTS en tablas). Algunos de ellos es evidente que no se van a producir (por ejemplo, aquellos en los que se hace uso de un fichero, ya que no hago uso de ellos), pero otros....no se ni de que me están hablando.

Entonces....hay algun listado típico/standart/común de errores a tener en cuenta en un proceso de registro??

Muchas gracias por la atención.

Un saludo a todos.

[gnzsoloyo]

Entonces....hay algun listado típico/standart/común de errores a tener en cuenta en un proceso de registro??

En realidad, esa lista la puedes armar con sólo pensar qué cosas pueden salir mal:
1) Clave duplicada (si el valor PK lo mandas directamente).
2) Valor NULL en un NOT NULL.
3) Error de sintaxis.
4) Error de conexión.
5) Falta de permisos.
6) Perdida de conexión.
7) Fallo de servidor.
8) Bloqueo por transacciones en curso.
9) Otros errores de validaciones que tu mismo hayas programado, cuyos errores funcionales sólo puedes administrar tú.

En definitiva, más allá de algunos casos genéricos, todo el resto son cosas que corresponden a excepciones que deberás gestionar tu mismo, posiblemente por fuera del SP, en la aplicación.

Al menos es así como se hace en todos los sistemas en los que he trabajado.

En algunos de ellos, inclusive, se sabe que un determinado proceso puede regresar una excepción por más de una docena de razones, pero el usuario sólo debe recibir un único mensaje.
¿Qué se hace entonces?
Simple: Se devuelve el mensaje más importante, y si hay más de uno de mayor jerarquía, se devuelve un error genérico, para que consulte a soporte técnico, y el mensaje de error real (o todos los errores detectados y capturados) se asientan en un log especial, oculto al usuario.
¿Por qué de ese modo?
Por que el 99,99% de los errores no son entendibles por los usuarios, pero sí son información técnica importante para los de soporte.

Todo esto quiere decir que en los SP sólo debes capturar el error puntual más trascendente, y dejar que el error de ejecución entregue a la aplicación el resto, a fin de que pueda loguear y ser usada con posterioridad, es decir que sólo debes ocuparte de aquellos errores de las sentencias y los datos, y no del resto. El resto se gestiona en el soporte del software.

¿Se va entendiendo?

[oms02]

Sí, mucho mejor; al menos, mucho más tranquilo.

Tan solo una pequeña duda.

Todo esto quiere decir que en los SP sólo debes capturar el error puntual más trascendente, y dejar que el error de ejecución entregue a la aplicación el resto, a fin de que pueda loguear y ser usada con posterioridad, es decir que sólo debes ocuparte de aquellos errores de las sentencias y los datos, y no del resto. El resto se gestiona en el soporte del software.

Tu último párrafo, digamos que me desconcierta un poco. Aunque creo que se a que te refieres, no se como lograr eso. Cuando tengas tiempo, ¿Podrías ponerme un ejemplo rápido mostrandome eso?

Gracias por los consejos gnzsoloyo.

Un saludo!

[gnzsoloyo]

La gestión de excepciones es tema de programación y por tanto OFF-TOPIC de este foro. Además, como depende de cada lenguaje la forma adecuada (no existe el concepto de "mejor" en desarrollo), deberás preguntar en el foro de tu lenguaje.
Y en cualquier caso, eso es algo que puedes ver en cualquier manual del lenguaje, porque el manejo de excepciones es para toda excepción en el proceso programado. La única adición en este caso es que se pueden capturar en ese momento los que provienene exclusivamente de acciones con la base de datos.

PD:
Si te preguntas por qué no te pongo códigos de ese tipo como ejemplo. es simple: Las reglas de este foro explícitamente dicen que no se postean códigos no SQL.

[oms02]

Lo comprendo. Perfect de todos modos. Por tus palabras, ahora se exactamente a que te referías. (parece que estamos jugando a Tabu )
Andaba un poco descolocado.

En realidad tengo un par de dudas más. Probablemente porque aún no he indagado lo suficiente sobre el asunto. Pido disculpas si estoy siendo muy pesado.

1. La idea es implementar EXIT HANDLER si se produce algún error y TRANSACTION para evitar inconsistencias en las tablas. El manual dice lo siguiente sobre HANDLER:

Para un handler CONTINUE , continúa la rutina actual tras la ejecución del comando del handler. Para un handler EXIT , termina la ejecución del comando compuesto BEGIN...END actual.

Me pregunto; si se produce un error y ya se han realizado uno o varios INSERT, el HANDLER termina la ejecución en ese mismo instante, pero no deshace lo hecho hasta ese momento, ¿cierto?.....para lo cual entra en juego TRANSACTION.... ¿es asi?

2. En tu comentario:

...porque el manejo de excepciones es para toda excepción en el proceso programado. La única adición en este caso es que se pueden capturar en ese momento los que provienene exclusivamente de acciones con la base de datos.

Si tiro el proceso hacia atrás con TRANSACTION o bien uso un EXIT HANDLER, el error no llegará a la parte del proceso programado, ¿no?, en ese caso....me quedo sin información del error....

No se si estoy en lo correcto.

Una vez más te(os) agradezco el tiempo empleado en mis dudas.

Un saludo.