Wenn in Ihrem T-SQL etwas schief geht, möchten Sie das Problem schnell mit minimalem Herumwühlen und Beeinträchtigung der Benutzer beheben. Von SQL Server generierte Fehlermeldungen sind sehr technisch und schwer zu verstehen, was die Isolierung von Problemen erschweren und die Lösungszeit verlangsamen kann. Glücklicherweise können DBAs SQL Server RAISERROR als Alternative zu SQL Server-Fehlermeldungen implementieren.
RAISERROR ist eine SQL Server-Fehlerbehandlungsanweisung, die eine Fehlermeldung generiert und die Fehlerverarbeitung initiiert. RAISERROR kann entweder auf eine benutzerdefinierte Nachricht verweisen, die in der Katalogansicht von sys.messages gespeichert ist, oder es kann eine Nachricht dynamisch erstellen. Die Nachricht wird als Serverfehlernachricht an die aufrufende Anwendung oder an einen zugeordneten CATCH-Block eines TRY...CATCH-Konstrukts zurückgegeben.
Es gibt mehrere Szenarien, in denen es angebracht ist, die RAISERROR-Anweisung zu verwenden:
- Fehlerbehebung bei Transact-SQL-Code
- Rückgabe von Nachrichten, die variablen Text enthalten
- Untersuchen von Datenwerten
- Wenn Sie die Ausführung benötigen, um von einem TRY-Block zum zugehörigen CATCH-Block zu springen oder Fehlerinformationen vom CATCH-Block an die Aufrufer zurückzugeben
Es ist wichtig zu beachten, dass bei der Entwicklung neuer Anwendungen eine THROW-Anweisung jetzt RAISERROR für die Fehlerbehandlung vorzuziehen ist. Aber dazu später mehr.
Warum RAISERROR für die SQL Server-Fehlerbehandlung verwenden?
Es gibt zwei Hauptgründe dafür, RAISERROR der von SQL Server generierten Fehlerbehandlung vorzuziehen:
- Die RAISERROR-Meldungen sind hinsichtlich Schweregrad und Status anpassbar
- Sie können in natürlicher, leicht verständlicher Sprache verfasst sein
RAISERROR gibt Fehlermeldungen an die Anwendung in demselben Format zurück, das von SQL Server Database Engine generiert wird. Es ermöglicht Entwicklern, ihre eigenen Fehlermeldungen zu generieren, sodass jeder, der die Nachricht liest, verstehen kann, was das eigentliche Problem ist, anstatt zu versuchen, die technische Fehlermeldung von SQL Server zu entschlüsseln. Entwickler können auch ihren eigenen Schweregrad, ihre Nachrichten-ID und ihren Status für Fehlermeldungen festlegen.
Verwendung von RAISERROR mit dem TRY...CATCH-Konstrukt
TRY...CATCH ist ein Fehlerbehandlungskonstrukt, mit dem Sie Code im TRY-Abschnitt ausführen und Fehler im CATCH-Abschnitt behandeln können. Im Allgemeinen ist TRY...CATCH eine effektive Möglichkeit, viele T-SQL-Fehler zu identifizieren, aber es gibt ein paar Ausnahmen.
Dieses Tutorial bietet eine detaillierte Anleitung zur Verwendung von RAISERROR in Verbindung mit TRY...CATCH. Der Autor verwendet ein Beispiel, das zeigt, wie der RAISERROR innerhalb eines TRY-Blocks verwendet wird, um zu bewirken, dass die Ausführung zum zugehörigen CATCH-Block springt. Innerhalb des CATCH-Blocks demonstriert der Autor, wie RAISERROR verwendet wird, um die Fehlerinformationen zurückzugeben, die den CATCH-Block aufgerufen haben. Die Ausgabe zeigt die Nachrichten-ID, den Schweregrad und den Fehlerstatus an.
RAISERROR vs. THROW-Anweisungen zur Fehlerbehandlung
RAISERROR wurde in SQL Server 7.0 eingeführt und ist seit vielen Jahren eine effektive Methode zur Behandlung von T-SQL-Fehlern. Aber wenn Sie neue Apps entwickeln, empfiehlt Microsoft jetzt die Verwendung von THROW-Anweisungen anstelle von RAISERROR.
Da Organisationen auf SQL Server 2012 und höher aktualisieren, wird RAISERROR auslaufen. Tatsächlich kann RAISERROR nicht in den nativ kompilierten Stored Procedures von SQL Server 2014 verwendet werden. THROW wird als Verbesserung gegenüber RAISERROR angesehen, da es einfacher zu verwenden ist.
Die SQL Server-Dokumentation von Microsoft schlüsselt die Unterschiede zwischen den RAISERROR- und THROW-Fehlerbehandlungsanweisungen wie folgt auf:
RAISERROR-Anweisung
- Wenn eine msg_id an RAISERROR übergeben wird, muss die ID in sys.messages definiert werden.
- Der Parameter msg_str kann printf-Formatierungsstile enthalten.
Der Severity-Parameter gibt den Schweregrad der Ausnahme an.
THROW-Anweisung
- Der Parameter error_number muss nicht in sys.messages definiert werden.
- Der Nachrichtenparameter akzeptiert keine Formatierung im printf-Stil.
- Es gibt keinen Parameter für den Schweregrad. Der Schweregrad der Ausnahme ist immer auf 16 festgelegt.
Obwohl die Tage von RAISERROR gezählt sein mögen, bleibt es eine praktikable Option zur Fehlerbehandlung auf älteren Versionen von SQL Server. Microsoft drängt Benutzer neuerer Versionen von SQL Server (SQL SERVER 2012 und höher), die THROW-Anweisung anstelle von RAISERROR für die Implementierung der Fehlerbehandlung zu verwenden. Microsoft hat die Einstellung von RAISERROR noch nicht angekündigt, aber es scheint wahrscheinlich, dass dies eher früher als später der Fall sein wird.
