Oto część szablonu procedury składowanej, którego używam:
/* 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 */
Bloki Try/Catch mogą być trudne, ale są znacznie dokładniejsze niż @@error. Co ważniejsze, możesz używać w nich różnych funkcji error_xxx(). Tutaj przechowuję poprawny komunikat o błędzie w zmiennej @ErrorMessage, wraz z wystarczającą ilością innych danych, aby ponownie zgłosić błąd. Stąd dostępna jest dowolna liczba opcji; możesz uczynić @ErrorMessage zmienną wyjściową, testować i obsługiwać określone błędy lub tworzyć własne komunikaty o błędach (lub dostosować istniejące, aby były bardziej przejrzyste -- możesz się irytować, gdy dowiadujesz się, jak często chcesz to robić). Inne opcje zaprezentują się same.
Coś, na co należy zwrócić uwagę:w niektórych sytuacjach SQL wyrzuci dwa komunikaty o błędach z powrotem... i error_message() złapie tylko ostatni, który zwykle mówi coś w rodzaju „próba utworzenia obiektu nie powiodła się”, z prawdziwym błędem podanym w pierwszym komunikacie o błędzie. W tym miejscu pojawia się tworzenie własnego komunikatu o błędzie.
