Implémenter une gestion structurée des exceptions

  • 3 minutes

Maintenant que vous comprenez la nature des erreurs et la gestion de base des erreurs 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 allez voir comment l’utiliser et évaluer ses avantages, mais également ses limitations, notamment le bloc TRY CATCH, le rôle des fonctions de gestion d’erreur et comprendre la différence entre les erreurs saisissables et non saisissables. Vous allez enfin voir comment les erreurs peuvent être gérées et signalées lorsque cela est nécessaire.

Qu’est-ce que la programmation de bloc TRY/CATCH ?

La gestion structurée des exceptions est plus puissante que la gestion des erreurs basée sur la variable système @@ERROR. Elle vous permet d’empêcher le décodage du code 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 sur l’objectif du code plutôt que sur la gestion des erreurs qu’il contient.

Bloc TRY et bloc CATCH

Lors de l’utilisation de la gestion structurée des exceptions, le code susceptible de déclencher une erreur est placé dans un bloc TRY. Les blocs TRY sont encadrés par les instructions BEGIN TRY et END TRY.

Si une erreur détectable se produit (la plupart des erreurs peuvent être détectées), le contrôle d’exécution passe au bloc CATCH. Le bloc CATCH est une série d’instructions T-SQL entourées par les instructions BEGIN CATCH et END CATCH.

Notes

Tandis que BEGIN CATCH et END TRY sont des instructions distinctes, le bloc BEGIN CATCH doit immédiatement suivre END TRY.

Limites actuelles

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

Comprendre la différence entre les erreurs détectables et les erreurs indétectables

Il est important de comprendre que si les blocs TRY/CATCH vous permettent d’intercepter un éventail d’erreurs beaucoup plus large qu’avec @@ERROR, vous ne pouvez pas intercepter tous les types.

Erreurs détectables et erreurs indétectables

Toutes les erreurs ne peuvent pas être détectées par des blocs TRY/CATCH au sein de la même étendue contenant le bloc TRY/CATCH. Souvent, les erreurs indétectables dans la même étendue peuvent être détectées dans une étendue environnante. Par exemple, vous ne pourrez peut-être pas détecter une erreur dans la procédure stockée qui contient le bloc TRY/CATCH. Mais vous pouvez détecter 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 indétectables courantes

Voici des exemples courants d’erreurs indétectables :

  • Les 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, généralement liés à 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 objectid.

Comment lever à nouveau des erreurs à l’aide de THROW

Si l’instruction THROW est utilisée dans un bloc CATCH sans aucun paramètre, elle lève à nouveau 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 détectant les erreurs et en consignant leurs détails, puis en levant l’erreur d’origine dans l’application cliente, afin qu’elle puisse être gérée à cet emplacement.

Voici un exemple d’une nouvelle levée d’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, il n’existait aucune méthode permettant de lever une erreur système. Alors que THROW ne peut pas spécifier une erreur système à déclencher, si THROW est utilisée sans paramètres dans un bloc CATCH, l’instruction redéclenchera les erreurs système et utilisateur.

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

Les blocs CATCH rendent les informations relatives aux erreurs disponibles pendant toute la durée du bloc CATCH. Cela inclut les sous-étendues, notamment les procédures stockées, exécutées à partir du bloc CATCH.

Fonctions de gestion des erreurs

Vous devez vous rappeler que, durant la programmation avec @@ERROR, la valeur détenue par la variable système @@ERROR a été réinitialisée dès l’exécution de l’instruction suivante.

Autre avantage clé de la gestion structurée des exceptions dans T-SQL : une série de fonctions de gestion des erreurs est fournie et ces fonctions conservent leurs valeurs dans le bloc CATCH. Des fonctions distinctes fournissent chaque propriété d’une erreur déclenché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 relatives aux erreurs disponibles pendant toute la durée du bloc CATCH.
  • @@Error est réinitialisé au moment de l’exécution de l’instruction suivante.

Gérer des erreurs dans le code

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

Erreurs dans le code managé

En général, vous souhaiterez peut-être détecter autant que possible les erreurs dans le code managé. Toutefois, il est important de se rendre compte que toutes les erreurs non gérées dans le code managé sont repassées au code T-SQL appelant. Chaque fois qu’une erreur survenue dans le code managé est retournée à SQL Server, il s’agit d’une erreur 6522. Les erreurs peuvent être imbriquées et cette erreur précise encapsule l’origine réelle de l’erreur.

Autre cause rare mais possible des erreurs dans le code managé : le code peut exécuter une instruction RAISERROR T-SQL via un objet SqlCommand.