Antwort.

In Stored Procedures sollten Fehler mit speziellen Konstruktionen behandelt werden.

In SQL Server sind die Hauptmechanismen die TRY...CATCH-Blöcke, in denen alle Fehler innerhalb von TRY gefangen werden, und in CATCH können die Details protokolliert werden. Funktionen wie ERROR_NUMBER(), ERROR_MESSAGE() stehen zur Verfügung, um Details zu erhalten.

BEGIN TRY
    -- Risikobehaftete Operation
    UPDATE Accounts SET balance = balance - 100 WHERE id = 1;
END TRY
BEGIN CATCH
    INSERT INTO ErrorLog(
        ErrorTime, ErrorNumber, ErrorMessage, UserName
    ) VALUES (
        GETDATE(), ERROR_NUMBER(), ERROR_MESSAGE(), SUSER_SNAME()
    );
    -- Zusätzliche Wiederherstellung oder ROLLBACK
END CATCH

In Oracle werden häufiger EXCEPTION-Blöcke verwendet:

BEGIN
    UPDATE ...;
EXCEPTION
    WHEN OTHERS THEN
        INSERT INTO error_log VALUES (..., SQLERRM);
END;

Wichtige Punkte, an die man denken sollte:

Nicht alle Fehler werden von CATCH erfasst, zum Beispiel werden Parsing- oder Kompilierungsfehler die Transaktion vor dem Eintritt in TRY zurücksetzen.
Für das Protokollieren von Informationen ist es wichtig, eine separate Tabelle für Fehler zu haben.
Es sollte so viel wie möglich protokolliert werden: Fehlermeldung, Nummer, Benutzername, Operation-Parameter.
In verschiedenen DBMS unterscheiden sich Syntax und Möglichkeiten.

Fangfrage.

Kann eine Ausnahme im CATCH-Block zum Verlust des Fehlerkontexts führen? Wie kann man eine geschachtelte Fehlerbehandlung implementieren?

Antwort und Beispiel: Wenn im CATCH-Block ein Fehler auftritt (zum Beispiel durch den Zugriff auf die Tabelle ErrorLog), geht der ursprüngliche Fehlerkontext verloren, und Informationen über die Ursache des Fehlers können verloren gehen.

Um dies zu verhindern, kapseln Sie das Protokollieren in eine separate Prozedur mit eigenem TRY...CATCH, um immer "Fehler im Fehlerhandler" zu erfassen.

BEGIN TRY
    -- Hauptcode
END TRY
BEGIN CATCH
    EXEC LogError @Error = ERROR_MESSAGE();
END CATCH
-- Die Prozedur LogError enthält selbst ihren eigenen TRY...CATCH

Geschichte

Projekt: Finanzberichterstattung. In Stored Procedures wurden TRY...CATCH-Blöcke hinzugefügt, aber die Parameter, mit denen der Fehler aufgetreten ist, wurden nicht protokolliert. Infolgedessen musste bei der Erfassung kritischer Fehler manuell die Situation aus dem Backup gesucht werden — die Ursache war nicht offensichtlich.

Geschichte

Projekt: Automatisierung des Dokumentenmanagements (Oracle). Im EXCEPTION-Block wurde vergessen, den Benutzernamen zu protokollieren. Nach einer Woche der Untersuchung stellte sich heraus, dass jemand absichtlich Dokumente "verändert" hatte — dies wurde nur durch indirekte Anzeichen im Auditprotokoll festgestellt.

Geschichte

Projekt: E-Commerce. Die Prozedur protokollierte bei einem Fehler einen Eintrag in ErrorLog. Eines Tages war die Log-Tabelle durch eine wuchernde Transaktion gesperrt, und der Versuch, zu protokollieren, führte zu einem geschachtelten Fehler, der die ursprüngliche Ursache überschritt und den Fehlerstapel löschte. Wir haben das durch die Implementierung einer zusätzlichen Tabelle für kritische Fehler und mehrstufiges Protokollieren behoben.

Wie implementiert man effektive Fehlerbehandlungs- und Debugging-Prozeduren in SQL Stored Procedures? Welche Mechanismen sind für das Abfangen und Protokollieren von Fehlern vorgesehen? Unterscheiden sich diese Ansätze zwischen verschiedenen DBMS?

Antwort.

Fangfrage.