Cita: 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?