Implémenter la gestion des exceptions structurées

Effectué

Maintenant que vous avez une compréhension de la nature des erreurs et de la gestion des erreurs de base dans T-SQL, il est temps d’examiner une forme plus avancée de gestion des erreurs. La gestion structurée des exceptions a été introduite dans SQL Server 2005.

Ici, vous verrez comment l’utiliser et évaluer ses avantages et ses limitations, notamment le bloc TRY CATCH, le rôle des fonctions de gestion des erreurs et comprendre la différence entre les erreurs interceptables et noncatchables. Enfin, vous verrez comment les erreurs peuvent être gérées et exposées si nécessaire.

Présentation de la programmation de blocs TRY/CATCH

La gestion structurée des exceptions est plus puissante que la gestion des erreurs basée sur la variable système @@ERROR. Il vous permet d’empêcher le code d’être litté avec le code de gestion des erreurs et de centraliser ce code de gestion des erreurs. La centralisation du code de gestion des erreurs signifie également que vous pouvez vous concentrer davantage sur l’objectif du code plutôt que sur la gestion des erreurs qu’il contient.

Bloc TRY et bloc CATCH

Lorsque vous utilisez la gestion des exceptions structurées, le code susceptible de déclencher une erreur est placé dans un bloc TRY. Les blocs TRY sont placés entre les instructions BEGIN TRY et END TRY .

Si une erreur interceptable se produit : la plupart des erreurs peuvent être interceptées, le contrôle d’exécution passe au bloc CATCH. Le bloc CATCH est une série d’instructions T-SQL placées entre les instructions BEGIN CATCH et END CATCH .

Remarque

Bien que BEGIN CATCH et END TRY soient des instructions distinctes, BEGIN CATCH doit immédiatement suivre END TRY.

Limitations actuelles

Les langages de haut niveau offrent souvent une construction try/catch/finally et sont souvent utilisés pour libérer implicitement des ressources. Il n’existe aucun bloc FINALLY équivalent dans T-SQL.

Comprendre la différence entre les erreurs interceptables et noncatchables

Il est important de se rendre compte que, alors que les blocs TRY/CATCH vous permettent d’intercepter une plage d’erreurs beaucoup plus large que possible avec @@ERROR, vous ne pouvez pas intercepter chaque type.

Erreurs interceptables et noncatchables

Toutes les erreurs ne peuvent pas être interceptées par des blocs TRY/CATCH dans la même étendue que celle du bloc TRY/CATCH. Souvent, les erreurs qui ne peuvent pas être interceptées dans la même étendue peuvent être interceptées dans une étendue environnante. Par exemple, vous ne pourrez peut-être pas intercepter une erreur dans la procédure stockée qui contient le bloc TRY/CATCH. Toutefois, vous êtes susceptible d’intercepter cette erreur dans un bloc TRY/CATCH dans le code qui a appelé la procédure stockée où l’erreur s’est produite.

Erreurs non modifiables courantes

Voici des exemples courants d’erreurs noncatchables :

• Erreurs de compilation, telles que les erreurs de syntaxe, qui empêchent la compilation d’un lot.
• Problèmes de recompilation au niveau de l’instruction qui se rapportent généralement à la résolution de noms différée. Par exemple, vous pouvez créer une procédure stockée qui fait référence à une table inconnue. Une erreur est levée uniquement lorsque la procédure tente de résoudre le nom de la table en un objectid.

Comment recréer des erreurs à l’aide de THROW

Si l’instruction THROW est utilisée dans un bloc CATCH sans aucun paramètre, elle réexécise l’erreur qui a provoqué l’entrée du code dans le bloc CATCH. Vous pouvez utiliser cette technique pour implémenter la journalisation des erreurs dans la base de données en interceptant les erreurs et en journalisant leurs détails, puis en lisant l’erreur d’origine dans l’application cliente, afin qu’elle puisse être gérée là-bas.

Voici un exemple de réexécriture d’une erreur.

BEGIN TRY
    -- code to be executed
END TRY
BEGIN CATCH
    PRINT ERROR_MESSAGE();
    THROW
END CATCH

Dans certaines versions antérieures de SQL Server, aucune méthode n’a été utilisée pour lever une erreur système. Si THROW ne peut pas spécifier d’erreur système à déclencher, lorsque THROW est utilisé sans paramètres dans un bloc CATCH, il réexécise les erreurs système et utilisateur.

Qu’est-ce que les fonctions de gestion des erreurs ?

Les blocs CATCH rendent les informations liées à l’erreur disponibles tout au long de la durée du bloc CATCH. Cela inclut des sous-étendues, telles que des procédures stockées, exécutées à partir du bloc CATCH.

Fonctions de gestion des erreurs

Rappelez-vous que, lors de la programmation avec @@ERROR, la valeur détenue par la variable système @@ERROR a été réinitialisée dès que l’instruction suivante a été exécutée.

Un autre avantage clé de la gestion structurée des exceptions dans T-SQL est qu’une série de fonctions de gestion des erreurs a été fournie et qu’elles conservent leurs valeurs dans tout le bloc CATCH. Les fonctions distinctes fournissent chaque propriété d’une erreur qui a été générée.

Cela signifie que vous pouvez écrire des procédures stockées de gestion des erreurs génériques qui peuvent toujours accéder aux informations relatives aux erreurs.

• Les blocs CATCH rendent les informations liées à l’erreur disponibles tout au long de la durée du bloc CATCH.
• @@Error est réinitialisé lorsque l’instruction suivante est exécutée.

Gérer les erreurs dans le code

L’intégration de SQL CLR permet l’exécution du code managé dans SQL Server. Les langages .NET de haut niveau, tels que C# et VB, ont une gestion détaillée des exceptions à leur disposition. Les erreurs peuvent être interceptées à l’aide des blocs .NET standard try/catch/finally.

Erreurs dans le code managé

En général, vous souhaiterez peut-être intercepter les erreurs dans le code managé autant que possible. Il est important de réaliser, cependant, que toutes les erreurs non gérées dans le code managé sont passées au code T-SQL appelant. Chaque fois qu’une erreur se produit dans le code managé est retournée à SQL Server, il semble qu’il s’agit d’une erreur 6522. Les erreurs peuvent être imbriquées et cette erreur particulière est encapsulée à la cause réelle de l’erreur.

Une autre cause rare mais possible d’erreurs dans le code managé serait que le code pourrait exécuter une instruction RAISERROR T-SQL via un objet SqlCommand.