TRY...CATCH (Transact-SQL)

Dans la portée d'un bloc CATCH, les fonctions système suivantes peuvent être utilisées pour obtenir des informations sur l'erreur qui a entraîné l'exécution du bloc CATCH :

• ERROR_NUMBER() renvoie le numéro de l'erreur.

• ERROR_SEVERITY() renvoie la gravité de l'erreur.

• ERROR_STATE() renvoie le numéro d'état de l'erreur.

• ERROR_PROCEDURE() renvoie le nom de la procédure stockée ou du déclencheur dans lequel s'est produit l'erreur.

• ERROR_LINE() renvoie le numéro de ligne au sein de la routine qui a entraîné l'erreur.

• ERROR_MESSAGE() renvoie le texte complet du message d'erreur. Ce texte comprend les valeurs fournies pour tous les paramètres substituables, tels que les longueurs, les noms d'objet ou les heures.

Ces fonctions renvoient la valeur NULL si elles sont appelées en dehors de l'étendue du bloc CATCH. Les informations sur les erreurs peuvent être récupérées à l'aide de ces fonctions à partir de n'importe quel emplacement dans l'étendue du bloc CATCH. Par exemple, le script suivant montre une procédure stockée contenant des fonctions de gestion des erreurs : dans le bloc CATCH d'une construction TRY…CATCH, la procédure stockée est appelée et les informations sur l'erreur sont retournées.

USE AdventureWorks2008R2;
GO
-- Verify that the stored procedure does not already exist.
IF OBJECT_ID ( 'usp_GetErrorInfo', 'P' ) IS NOT NULL 
    DROP PROCEDURE usp_GetErrorInfo;
GO

-- Create procedure to retrieve error information.
CREATE PROCEDURE usp_GetErrorInfo
AS
SELECT
    ERROR_NUMBER() AS ErrorNumber
    ,ERROR_SEVERITY() AS ErrorSeverity
    ,ERROR_STATE() AS ErrorState
    ,ERROR_PROCEDURE() AS ErrorProcedure
    ,ERROR_LINE() AS ErrorLine
    ,ERROR_MESSAGE() AS ErrorMessage;
GO

BEGIN TRY
    -- Generate divide-by-zero error.
    SELECT 1/0;
END TRY
BEGIN CATCH
    -- Execute error retrieval routine.
    EXECUTE usp_GetErrorInfo;
END CATCH;

Les constructions TRY…CATCH n'interceptent pas les conditions suivantes :

• Les avertissements ou messages d'information dont la gravité est inférieure ou égale à 10.

• Les erreurs dont le niveau de gravité est supérieur ou égal à 20 interrompent le traitement des tâches du moteur de base de données SQL Server pour la session. Si une erreur dont le niveau de gravité est supérieur ou égal à 20 survient et que la connexion à la base de données n'est pas interrompue, TRY…CATCH gère l'erreur.

• Un événement d'avertissement, tel qu'une requête d'interruption par le client ou une rupture de connexion avec le client, se produit.

• Cela survient lorsque la session est terminée par un administrateur système utilisant l'instruction KILL.

Les types d'erreur suivants ne sont pas gérés par un bloc CATCH lorsqu'ils surviennent au même niveau d'exécution que la construction TRY…CATCH :

• Les erreurs de compilation, telles que les erreurs de syntaxe, qui empêchent un traitement de s'exécuter.

• Les erreurs qui se produisent pendant une recompilation de niveau instruction, telles que les erreurs de résolution de nom d'objet qui surviennent après la compilation en raison d'une résolution de nom différée.

Ces erreurs sont renvoyées au niveau qui a exécuté le traitement, la procédure stockée ou le déclencheur.

Si une erreur survient pendant la compilation ou la recompilation au niveau de l'instruction à un niveau d'exécution inférieur (par exemple, lors de l'exécution de sp_executesql ou d'une procédure stockée définie par l'utilisateur) à l'intérieur du bloc TRY, l'erreur survient à un niveau inférieur à la construction TRY…CATCH et sera gérée par le bloc CATCH associé. Pour plus d'informations, consultez Utilisation de TRY...CATCH dans Transact-SQL.

L'exemple suivant montre comment une erreur de résolution de noms d'objets générée par une instruction SELECT n'est pas interceptée par la construction TRY…CATCH, mais par le bloc CATCH lorsque la même instruction SELECT est exécutée au sein d'une procédure stockée.

USE AdventureWorks2008R2;
GO

BEGIN TRY
    -- Table does not exist; object name resolution
    -- error not caught.
    SELECT * FROM NonexistentTable;
END TRY
BEGIN CATCH
    SELECT 
        ERROR_NUMBER() AS ErrorNumber
        ,ERROR_MESSAGE() AS ErrorMessage;
END CATCH

L'erreur n'est pas interceptée et le contrôle est passé de la construction TRY…CATCH au niveau supérieur suivant.

L'exécution de l'instruction SELECT au sein d'une procédure stockée entraîne l'occurrence de l'erreur à un niveau inférieur à celui du bloc TRY. L'erreur sera gérée par la construction TRY…CATCH.

-- Verify that the stored procedure does not exist.
IF OBJECT_ID ( N'usp_ExampleProc', N'P' ) IS NOT NULL 
    DROP PROCEDURE usp_ExampleProc;
GO

-- Create a stored procedure that will cause an 
-- object resolution error.
CREATE PROCEDURE usp_ExampleProc
AS
    SELECT * FROM NonexistentTable;
GO

BEGIN TRY
    EXECUTE usp_ExampleProc;
END TRY
BEGIN CATCH
    SELECT 
        ERROR_NUMBER() AS ErrorNumber
        ,ERROR_MESSAGE() AS ErrorMessage;
END CATCH;

• Pour plus d'informations sur les traitements, consultez Traitements.

Si une erreur générée dans un bloc TRY entraîne l'invalidation de la transaction actuelle, elle est classifiée comme transaction non validable. Une erreur qui termine normalement une transaction en dehors d'un bloc TRY fait entrer la transaction dans un état non validable lorsqu'elle survient au sein d'un bloc TRY. Une transaction non validable ne peut effectuer que des opérations de lecture ou ROLLBACK TRANSACTION. La transaction ne peut exécuter aucune instruction Transact-SQL qui générerait une opération d'écriture ou COMMIT TRANSACTION. La fonction XACT_STATE renvoie une valeur de -1 si une transaction a été classifiée comme non validable. Lorsqu'un traitement est terminé, le moteur de base de données restaure automatiquement toutes les transactions non validables actives. Si aucun message d'erreur n'a été envoyé lorsque la transaction est passée dans un état non validable, une erreur est envoyée à l'application cliente lorsque le traitement se termine. Cela indique qu'une transaction non validable a été détectée et annulée.

Pour plus d'informations sur les transactions non validables et la fonction XACT_STATE, consultez Utilisation de TRY...CATCH dans Transact-SQL et XACT_STATE (Transact-SQL).

L'exemple suivant illustre une instruction SELECT qui génère une erreur de division par zéro. L'erreur entraîne le saut de l'exécution vers le bloc CATCH associé.

USE AdventureWorks2008R2;
GO

BEGIN TRY
    -- Generate a divide-by-zero error.
    SELECT 1/0;
END TRY
BEGIN CATCH
    SELECT
        ERROR_NUMBER() AS ErrorNumber
        ,ERROR_SEVERITY() AS ErrorSeverity
        ,ERROR_STATE() AS ErrorState
        ,ERROR_PROCEDURE() AS ErrorProcedure
        ,ERROR_LINE() AS ErrorLine
        ,ERROR_MESSAGE() AS ErrorMessage;
END CATCH;
GO

L'exemple suivant montre comment un bloc TRY…CATCH fonctionne dans une transaction. L'instruction dans le bloc TRY génère une erreur de violation de contrainte.

USE AdventureWorks2008R2;
GO
BEGIN TRANSACTION;

BEGIN TRY
    -- Generate a constraint violation error.
    DELETE FROM Production.Product
    WHERE ProductID = 980;
END TRY
BEGIN CATCH
    SELECT 
        ERROR_NUMBER() AS ErrorNumber
        ,ERROR_SEVERITY() AS ErrorSeverity
        ,ERROR_STATE() AS ErrorState
        ,ERROR_PROCEDURE() AS ErrorProcedure
        ,ERROR_LINE() AS ErrorLine
        ,ERROR_MESSAGE() AS ErrorMessage;

    IF @@TRANCOUNT > 0
        ROLLBACK TRANSACTION;
END CATCH;

IF @@TRANCOUNT > 0
    COMMIT TRANSACTION;
GO

L'exemple suivant montre comment utiliser la construction TRY…CATCH pour gérer les erreurs qui surviennent dans une transaction. La fonction XACT_STATE détermine si la transaction doit être validée ou annulée. Dans cet exemple, SET XACT_ABORT est ON. Cela rend la transaction non validable lorsque l'erreur de violation de contrainte se produit.

USE AdventureWorks2008R2;
GO

-- Check to see whether this stored procedure exists.
IF OBJECT_ID (N'usp_GetErrorInfo', N'P') IS NOT NULL
    DROP PROCEDURE usp_GetErrorInfo;
GO

-- Create procedure to retrieve error information.
CREATE PROCEDURE usp_GetErrorInfo
AS
    SELECT 
        ERROR_NUMBER() AS ErrorNumber
        ,ERROR_SEVERITY() AS ErrorSeverity
        ,ERROR_STATE() AS ErrorState
        ,ERROR_LINE () AS ErrorLine
        ,ERROR_PROCEDURE() AS ErrorProcedure
        ,ERROR_MESSAGE() AS ErrorMessage;
GO

-- SET XACT_ABORT ON will cause the transaction to be uncommittable
-- when the constraint violation occurs. 
SET XACT_ABORT ON;

BEGIN TRY
    BEGIN TRANSACTION;
        -- A FOREIGN KEY constraint exists on this table. This 
        -- statement will generate a constraint violation error.
        DELETE FROM Production.Product
            WHERE ProductID = 980;

    -- If the DELETE statement succeeds, commit the transaction.
    COMMIT TRANSACTION;
END TRY
BEGIN CATCH
    -- Execute error retrieval routine.
    EXECUTE usp_GetErrorInfo;

    -- Test XACT_STATE:
        -- If 1, the transaction is committable.
        -- If -1, the transaction is uncommittable and should 
        --     be rolled back.
        -- XACT_STATE = 0 means that there is no transaction and
        --     a commit or rollback operation would generate an error.

    -- Test whether the transaction is uncommittable.
    IF (XACT_STATE()) = -1
    BEGIN
        PRINT
            N'The transaction is in an uncommittable state.' +
            'Rolling back transaction.'
        ROLLBACK TRANSACTION;
    END;

    -- Test whether the transaction is committable.
    IF (XACT_STATE()) = 1
    BEGIN
        PRINT
            N'The transaction is committable.' +
            'Committing transaction.'
        COMMIT TRANSACTION;   
    END;
END CATCH;
GO