Voici une partie d'un modèle de procédure stockée que j'utilise :
/* CREATE PROCEDURE... */
DECLARE
@ErrorMessage varchar(2000)
,@ErrorSeverity tinyint
,@ErrorState tinyint
/* Additional code */
BEGIN TRY
/* Your code here */
END TRY
BEGIN CATCH
SET @ErrorMessage = ERROR_MESSAGE()
SET @ErrorSeverity = ERROR_SEVERITY()
SET @ErrorState = ERROR_STATE()
RAISERROR(@ErrorMessage, @ErrorSeverity, @ErrorState)
BREAK
END CATCH
/* Further cleanup code */
Les blocs Try/Catch peuvent être délicats mais sont beaucoup plus approfondis que @@error. Plus important encore, vous pouvez utiliser les différentes fonctions error_xxx() qu'elles contiennent. Ici, je stocke le message d'erreur approprié dans la variable @ErrorMessage, ainsi que suffisamment d'autres données pour relancer l'erreur. À partir de là, un certain nombre d'options sont disponibles ; vous pouvez faire de @ErrorMessage une variable de sortie, tester et gérer des erreurs spécifiques, ou créer vos propres messages d'erreur (ou ajuster les messages existants pour qu'ils soient plus clairs - vous pourriez être irrité de savoir à quelle fréquence vous voudrez le faire). D'autres options se présenteront.
Quelque chose à surveiller :dans certaines situations, SQL renverra deux messages d'erreur dos à dos... et error_message() n'attrapera que le dernier, qui dit généralement quelque chose comme "la tentative de création d'objet a échoué", avec la véritable erreur indiquée dans le premier message d'erreur. C'est là qu'intervient la création de votre propre message d'erreur.
