none
Manejar error de sql desde capas RRS feed

  • Pregunta

  • Buenaa noches, tengo una aplicacion en capas 2, :'(, en la capa para acceso a loa datos usé throw para alertar algun error en la presentación. El problema,, es que si la tabla del sql tiene el campo como valor unico el vs si sale el error correctamente, pero sale un twxto algo largo que dlo dice que el canpo es unuci y esta repetida... el punto es, como controlo ese error?

    Giancarlo

    miércoles, 28 de febrero de 2018 6:05

Respuestas

  •  y como sabes el tipo de error de sql (el codigo), o de donde saco esa lista

    Puedes sacar la lista de ccodigos de error enviando esta consulta a SQL Server:

    select message_id, text from sys.messages where language_id=3082

    Para saber cual es el error que ha ocurrido, en el "catch ex as SqlException" puedes examinar ex.Number, que te da el correspondiente numero para buscar en esa lista. O si lo prefierres, dentro de "ex" tienes multiples propiedades que indican la clase, la severidad, el mensaje de error, etc.


    Otra pregunta que tengo es que despues de capturar la excepcion, no llega a la linea finally del try catch, solo se queda en el catch
    No, no es cierto. Compruebalo bien, veras como el Finally siempre se ejecuta, con independencia de que se ejecute el Catch o no. Es mas, de hecho el Finally se ejecuta incluso aunque hagas un "Return" dentro del Try o del Catch: primero hace el Finally, y luego ejecuta el return.
    • Marcado como respuesta gian2051 jueves, 1 de marzo de 2018 6:34
    miércoles, 28 de febrero de 2018 13:45

Todas las respuestas

  • Cuando trabajas en capas, lo correcto es que cada capa procese los errores propios de esa capa y solo pase a capas superiores los errores que puedan ser "entendidos" en esas capas.

    Si tienes una capa de datos que accede a Sql, en esa capa puedes capturar con el Try...Catch el SqlException, y analizar el contenido, mirando el número de excepción y según cuál sea tomar la medidas necesarias. Pero no debes hacer un "Throw", porque eso le pasa el SqlExcepton a la capa superior, pero esa capa no debería saber nada acerca de "Sql" (para eso has dividido el código en capas). En su lugar, haz algo así como Throw New ApplicationException("Dato repetido") o similar, para pasarle a la capa superior algo que ésta pueda comprender.

    miércoles, 28 de febrero de 2018 7:32
  • Entiendo, sería 

    Try

    Instrucciones

    Catch ex as sqlexceptoon

    End try

    Mi pregunta sería, y como sabes el tipo de error de sql (el codigo), o de donde saco esa lista, es decir, como saber si el error se debe a que hibo error en la transaccion, campps unicos, claves foraneas, en fin.

    Otra pregunta que tengo es que despues de capturar la excepcion, no llega a la linea finally del try catch, solo se queda en el catch, como haría? Por ahora, (no se me ocurrio orra cosa) en el finally y e el catch puse para cerrar la conexion sql


    Giancarlo

    miércoles, 28 de febrero de 2018 12:51
  •  y como sabes el tipo de error de sql (el codigo), o de donde saco esa lista

    Puedes sacar la lista de ccodigos de error enviando esta consulta a SQL Server:

    select message_id, text from sys.messages where language_id=3082

    Para saber cual es el error que ha ocurrido, en el "catch ex as SqlException" puedes examinar ex.Number, que te da el correspondiente numero para buscar en esa lista. O si lo prefierres, dentro de "ex" tienes multiples propiedades que indican la clase, la severidad, el mensaje de error, etc.


    Otra pregunta que tengo es que despues de capturar la excepcion, no llega a la linea finally del try catch, solo se queda en el catch
    No, no es cierto. Compruebalo bien, veras como el Finally siempre se ejecuta, con independencia de que se ejecute el Catch o no. Es mas, de hecho el Finally se ejecuta incluso aunque hagas un "Return" dentro del Try o del Catch: primero hace el Finally, y luego ejecuta el return.
    • Marcado como respuesta gian2051 jueves, 1 de marzo de 2018 6:34
    miércoles, 28 de febrero de 2018 13:45
  • Muchas gracias, solo me faltaría ver cuales serían los errores que debería preocuparme y listo

    Giancarlo

    jueves, 1 de marzo de 2018 6:35