Tratamiento de errores del servidor SQL: excepciones y el contrato cliente-base de datos

Question

Somos un equipo de desarrolladores de bases de datos de servidores SQL. Nuestros clientes son una mezcla de servicios web C#/ASP.NET, C# y Java, servicios Java/Unix y algunos de Excel.

Nuestros desarrolladores de clientes solo utilizan los procedimientos almacenados que ofrecemos y esperamos que (cuando sea razonable, por supuesto) los traten como métodos de servicio web.

A algunos de nuestros desarrolladores de clientes no les gustan las excepciones SQL. Los entienden en sus idiomas pero no aprecian que el SQL esté limitado en la forma en que podemos comunicar los problemas.

No me refiero sólo a errores de SQL, como intentar insertar "bob" en una columna int.

También me refiero a excepciones como decirles que un valor de referencia es incorrecto, o que los datos ya han cambiado, o no pueden hacerlo porque su agregado no es cero.

Realmente no tienen ninguna alternativa concreta: han mencionado que debemos generar parámetros, pero suponemos que una excepción significa "procesamiento detenido/revertido".

¿Cómo manejan las personas aquí el contrato cliente-base de datos? Ya sea en general o donde hay separación entre el DB y los monos de código de cliente.

ediciones:

• usamos SQL Server 2005 TRY/CATCH exclusivamente
• registramos todos los errores después de la reversión a una tabla de excepción ya
• nos preocupa que algunos de nuestros clientes ganaron' Verifique los parámetros de salida y suponga que todo está bien. Necesitamos que se marquen los errores para que podamos ver el soporte.
• todo es una excepción ... se espera que los clientes analicen algunos mensajes para separar la información de los errores. Para separar nuestras excepciones del motor de DB y los errores de llamada, deben usar el número de error (los nuestros son todos 50,000 por supuesto)

Answer 1

Bueno, soy un mono de código de cliente que trata mucho con las bases de datos. Así es como lo manejo.

Las excepciones (raiseerrors) que ocurren en SQL se propagan de vuelta a la persona que llama. Esto incluiría restricciones de ref, violaciones únicas de índices, problemas más serios, etc. Básicamente cualquier cosa que no haría que la operación de datos ocurriera normalmente debería propagarse nuevamente.

La persona que llama C# debe tener presente:

catch (SQLException sqlEx) 

Y luego manejar la excepción, según sea necesario. Deben tener un controlador SQLException específico. Esto es importante.

Por lo general, me mantengo alejado de los parámetros de salida porque considero que están relacionados con los datos transportados y no con mensajes de error, además puedo inspeccionar la excepción del código de error SQL Server para que todos los datos que necesitamos estén en esa excepción

Además, en algunos casos con SQL Server, hemos almacenado procedimientos que podrían generar "tipo de negocio de excepciones". En esos casos agregamos un número de error personalizado (por encima de 50000) y aumentamos ese error en el procedimiento almacenado cuando sea necesario. En general, tratamos de mantener esto al mínimo porque agrega complejidad, pero en algunos casos, hemos encontrado que es necesario.

Ahora, dado que el cliente detecta la excepción SQLException, puede ver el código de error devuelto por SQL Server en la excepción y tomar cualquier acción especial (si es necesario) cuando se detecta la excepción y el número de error es cierto valor. Esto permite un nivel secundario de manejo de errores basado en el código de error si es necesario para los errores personalizados (> 50000).

Esto también permite que los DBA generen errores personalizados y que el código del cliente tenga una forma consistente de manejarlos. Los DBA tendrían que decirle al código del cliente cuáles eran los errores personalizados para poder prepararse para ellos.

Normalmente no utilizo los códigos de retorno para el manejo de errores, aunque puedo ver cómo se podrían usar, pero eso significa más lógica en la capa mono de código para ver y tratar el código de retorno. Si son un problema, quiero una excepción, porque entonces puedo lidiar con ellos de manera consistente. Si también tengo que mirar los códigos de retorno, ahora hay varias formas de manejar errores.

Answer 2

Generalmente utilizo un parámetro de salida y defino los valores posibles.

0 = éxito
Postive Entero (en un inserto digamos) = Nueva fila ID (@@ identity)

entero negativo = conocidos Condiciones de error posibles
-1 = @LastName no disponibles (o cero longitud)
-2 = @Nombre que faltan (o longitud cero)
... etc ...

Esto se vuelve un poco tedioso para definir - pero puede ser extensible - y es una manera de conseguir significativa resultados a sus clientes una nd para una capa de acceso a datos para volver a una capa de objetos comerciales una razón exacta para el fracaso (yo uso enumeraciones en la capa de Business Objects para diferentes condiciones de estado).

También es posible que una capa de acceso a datos genere excepciones si lo desea, pero creo que desde el punto de vista del costo es mejor que no arroje errores cuando puede verificar un valor enum o entero.

Existen otras técnicas, esta es solo una que he utilizado con cierto éxito en el pasado.

Answer 3

aquí es mi recomendación:

retorno 0 cuando todo está bien
retorno negativo cuando x hapens un error lógico, desaparecidos o datos no válidos
retorno x positivo cuando ocurre un error fatal, inserte el fracaso, etc.

agregue los parámetros de salida ErrorMsg y ErrorLog en los procedimientos almacenados. ErrorMessage contendrá un mensaje legible por humanos, ErrorLog contendrá información de depuración.
Estos serán NULL si devuelven 0
Puede usar ErrorLog para registrar cualquier problema, asegúrese de que si los está insertando en una tabla, lo hace después de la reversión.

use TRY - Capture para capturar problemas, y cree su propio mensaje, y devuelva la información utilizando las convenciones anteriores.

Answer 4

En mi trabajo actual, reservamos excepciones para condiciones excepcionales. Para cosas como parámetros incorrectos o similares, tenemos códigos de retorno estándar; los valores de parámetros no válidos siempre devuelven 98, por ejemplo. (¿por qué 98? que se perdió en la historia ...)

Esto no es necesariamente ideal b/c tanto el cliente como el SP tienen que entender lo que significa un código de retorno particular; es una mala separación de preocupaciones.

En casos especiales, utilizamos parámetros OUT para devolver mensajes, y nuestros servicios por lotes utilizan una configuración de tabla #scratch estandarizada.

En un empleador anterior, utilizamos errores de SQL personalizados para los mismos fines. Entonces, usa lo que tenga sentido. Personalmente, prefiero un mecanismo único, pero eso puede no ser posible dependiendo de su entorno.

Quizás todos ustedes deberían reunirse para desarrollar formas estandarizadas para que el código del cliente lo maneje. El VBA utilizado en Excel tiene distintas limitaciones que el C# y el código de Java no tienen, y tan similares como Java & C# son el uno para el otro, no son idénticos. Si va a seguir con las excepciones de devolución, entonces si puede aceptar a) un número de mensaje conocido # que indique excepciones de "error" yb) un diseño de mensaje estandarizado para que pueda realizarse un análisis estandarizado, los desarrolladores estarían 90% hecho.