cómo repensar la misma excepción en sql server

SQL 2012 introduce la sentencia throw:

Http://msdn.microsoft.com/en-us/library/ee677615.aspx

Si la instrucción THROW se especifica sin parámetros, debe aparecer dentro de un bloque de CAPTURA. Esto hace que la excepción atrapada se eleve.

BEGIN TRY
    BEGIN TRANSACTION
    ...
    COMMIT TRANSACTION
END TRY
BEGIN CATCH
    ROLLBACK TRANSACTION;
    THROW
END CATCH

Repensando dentro del bloque CATCH (código anterior a SQL2012, use la instrucción THROW para SQL2012 y posteriores):

DECLARE
    @ErrorMessage nvarchar(4000) = ERROR_MESSAGE(),
    @ErrorNumber int = ERROR_NUMBER(),
    @ErrorSeverity int = ERROR_SEVERITY(),
    @ErrorState int = ERROR_STATE(),
    @ErrorLine int = ERROR_LINE(),
    @ErrorProcedure nvarchar(200) = ISNULL(ERROR_PROCEDURE(), '-');
SELECT @ErrorMessage = N'Error %d, Level %d, State %d, Procedure %s, Line %d, ' + 'Message: ' + @ErrorMessage;
RAISERROR (@ErrorMessage, @ErrorSeverity, 1, @ErrorNumber, @ErrorSeverity, @ErrorState, @ErrorProcedure, @ErrorLine)

Creo que sus opciones son:

• No atrape el error (deje que burbujee)
• Levante una personalizada

En algún momento, SQL probablemente introducirá un comando reraise, o la capacidad de detectar solo ciertos errores. Pero por ahora, utilice una solución alternativa. Disculpe....

No se puede: solo el motor puede lanzar errores de menos de 50000. Todo lo que puede hacer es lanzar una excepción que se parece a...

Ver mi respuesta aquí, por favor,

El interrogador aquí utilizó transacciones del lado del cliente para hacer lo que quería, lo que creo que es un poco tonto...

Ok, esta es una solución...:-)

DECLARE @Error_Number INT
BEGIN TRANSACTION 
    BEGIN TRY
    INSERT INTO Test(Id, Name) VALUES (newID(),'Ashish') 
    /* Column 'Name' has unique constraint on it*/
    END TRY
    BEGIN CATCH

            SELECT ERROR_NUMBER()
            --RAISERROR (@ErrorMessage,@Severity,@State)
            ROLLBACK TRAN
    END CATCH

Si observa el bloque catch, no está elevando el error, sino devolviendo el número de error real (y también revertiría la transacción). Ahora en su código. NET, en lugar de capturar la exception, si usa ExecuteScalar (), obtiene el número de error real que desea y muestra el número apropiado.

int errorNumber=(int)command.ExecuteScalar();
if(errorNumber=<SomeNumber>)
{
    MessageBox.Show("Some message");
}

Espero que esto ayude,

EDITAR: - Solo una nota, si desea obtener el número de registros afectados y tratando de utilizar ExecuteNonQuery, la solución anterior puede no funcionar para usted. De lo contrario, creo que se adaptaría a lo que necesitas. Házmelo saber.

La forma de detener la ejecución en un procedimiento almacenado después de que se haya producido un error y devolver el error al programa que llama es seguir cada instrucción que pueda generar un error con este código:

If @@ERROR > 0
Return

Me sorprendió descubrir que la ejecución en un procedimiento almacenado puede continuar después de un error, sin darme cuenta de esto puede conducir a algunos errores difíciles de rastrear.

Este tipo de manejo de errores parallels (pre. net) Visual Basic 6. Esperando el comando de lanzamiento en SQL Server 2012.

Dado que aún no se ha movido a 2012, una forma de implementar el burbujeo del código de error original es usar la parte de mensaje de texto de la excepción que está (re)lanzando desde el bloque catch. Recuerde que puede contener alguna estructura, por ejemplo, texto XML para que su código de llamada lo analice en su bloque catch.

También puede crear un procedimiento almacenado wrapper para esos escenarios cuando desee que la instrucción SQL se ejecute dentro de la transacción y alimente el error a su código.

CREATE PROCEDURE usp_Execute_SQL_Within_Transaction
(
    @SQL nvarchar(max)
)
AS

SET NOCOUNT ON

BEGIN TRY
    BEGIN TRANSACTION
        EXEC(@SQL)
    COMMIT TRANSACTION
END TRY

BEGIN CATCH
    DECLARE @ErrorMessage nvarchar(max), @ErrorSeverity int, @ErrorState int
    SELECT @ErrorMessage = N'Error Number: ' + CONVERT(nvarchar(5), ERROR_NUMBER()) + N'. ' + ERROR_MESSAGE() + ' Line ' + CONVERT(nvarchar(5), ERROR_LINE()), @ErrorSeverity = ERROR_SEVERITY(), @ErrorState = ERROR_STATE()
    ROLLBACK TRANSACTION
    RAISERROR (@ErrorMessage, @ErrorSeverity, @ErrorState)
END CATCH

GO

-- Test it
EXEC usp_Execute_SQL_Within_Transaction @SQL = 'SELECT 1; SELECT 2'
EXEC usp_Execute_SQL_Within_Transaction @SQL = 'SELECT 1/0; SELECT 2'
EXEC usp_Execute_SQL_Within_Transaction @SQL = 'EXEC usp_Another_SP'

Desde el punto de vista del diseño, ¿cuál es el punto de lanzar excepciones con números de error originales y mensajes personalizados? Hasta cierto punto rompe el contrato de interfaz entre las aplicaciones y la base de datos. Si desea detectar errores originales y manejarlos en código superior, no los maneje en la base de datos. Luego, cuando atrapa una excepción, puede cambiar el mensaje presentado al usuario a cualquier cosa que desee. Yo no lo haría sin embargo, porque hace que su código de base de datos hmm ' no correcto. Como otros dijeron, debería definir un conjunto de sus propios códigos de error (por encima de 50000) y lanzarlos en su lugar. A continuación, puede hanle problemas de integridad ('No se permiten valores duplicados') por separado de los posibles problemas de negocio - 'Código postal no es válido', 'No se encontraron filas que coincidan con los criterios' y así sucesivamente.