Hier ist ein Teil einer Vorlage für gespeicherte Prozeduren, die ich verwende:
/* 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 */
Try/Catch-Blöcke können knifflig sein, sind aber viel gründlicher als @@error. Noch wichtiger ist, dass Sie die verschiedenen error_xxx()-Funktionen darin verwenden können. Hier speichere ich die richtige Fehlermeldung in der Variablen @ErrorMessage, zusammen mit genügend anderen Daten, um den Fehler erneut auszulösen. Von hier aus sind beliebig viele Optionen verfügbar; Sie könnten @ErrorMessage zu einer Ausgabevariablen machen, auf bestimmte Fehler testen und diese behandeln oder Ihre eigenen Fehlermeldungen erstellen (oder die vorhandenen anpassen, um sie klarer zu machen – Sie könnten irritiert sein, wenn Sie herausfinden, wie oft Sie das tun möchten). Weitere Optionen werden angezeigt.
Worauf Sie achten sollten:In manchen Situationen wirft SQL zwei Fehlermeldungen hintereinander ... und error_message() fängt nur die letzte ab, die normalerweise so etwas wie "Versuch, Objekt zu erstellen, fehlgeschlagen" sagt, wobei der eigentliche Fehler in der ersten Fehlermeldung angegeben wird. Hier kommt das Erstellen Ihrer eigenen Fehlermeldung ins Spiel.
