Antwort.

Jede industrielle SQL-Lösung erfordert eine durchdachte Architektur zur Fehlerbehandlung. Ohne Protokollierung und sorgfältige Ausnahmebehandlung ist es unmöglich, komplexe Prozesse zu debuggen, insbesondere in gespeicherten Prozeduren und Batch-Skripten.

Hintergrund: Standard-SQL erlaubt eine minimale Fehlerbehandlung (z.B. RETURN und Beendigung der Verarbeitung). Moderne Erweiterungen (T-SQL, PL/pgSQL, PL/SQL usw.) bieten vollständige Konstrukte zur Fehlerbehandlung (TRY/CATCH, EXCEPTION).

Problem: Ohne explizite Fehlerbehandlung „sinkt“ man, und es ist für den Administrator schwierig, die Ursache eines Fehlers zu ermitteln — insbesondere bei Massenänderungen oder der Arbeit mit externen Systemen. Oft gibt es die Anforderung, Fehler in einer separaten Tabelle zu protokollieren, um sie später zu analysieren.

Lösung: Verwenden Sie das Arsenal von TRY/CATCH (T-SQL) oder EXCEPTION (PL/pgSQL) sowie eigene Protokollierungstabellen. Vergessen Sie nicht, diagnostische Informationen (Fehlercode, Fehlermeldung, Abfrageparameter und Zeit) in das Protokoll zu senden.

Beispielcode (T-SQL, MS SQL Server):

CREATE TABLE ErrorLog (
    ErrorId INT IDENTITY PRIMARY KEY,
    ErrorTime DATETIME,
    ProcedureName NVARCHAR(128),
    ErrorMessage NVARCHAR(MAX),
    ErrorNumber INT,
    ErrorState INT,
    ErrorSeverity INT
);

CREATE PROCEDURE usp_ProcessOrders
AS
BEGIN
    BEGIN TRY
        -- Geschäftslogik
        UPDATE Orders SET Status = 'PROCESSED' WHERE Status = 'NEW';
    END TRY
    BEGIN CATCH
        INSERT INTO ErrorLog
        (
            ErrorTime, ProcedureName, ErrorMessage, ErrorNumber, ErrorState, ErrorSeverity
        )
        VALUES
        (
            GETDATE(),
            ERROR_PROCEDURE(),
            ERROR_MESSAGE(),
            ERROR_NUMBER(),
            ERROR_STATE(),
            ERROR_SEVERITY()
        );
        THROW;
    END CATCH
END

Beispielcode (PL/pgSQL, PostgreSQL):

BEGIN
    -- Ihr Code
EXCEPTION WHEN OTHERS THEN
    INSERT INTO error_log(ts, proc_name, err_text)
    VALUES(now(), 'my_proc', SQLERRM);
    RAISE;
END;

Hauptmerkmale:

Sofortiger Zugriff auf die Einzelheiten des Fehlers zur Fehlerbehebung.
Vollständige Nachverfolgbarkeit aller Phasen des Prozesses.
Brechen Sie die Ausführung nicht ohne explizite Rückgabe und zentrale Protokollierung.

Trickfragen.

Reicht es aus, den Fehler abzufangen und die Prozedur ohne Weitergabe von Informationen nach außen zu beenden?

Nein. Ohne explizite Protokollierung oder Weitergabe des Fehlers ist es unmöglich, die Ursachen des Ausfalls zu erfassen und zu analysieren. Es ist wichtig, entweder den Fehler detailliert im Protokoll zu dokumentieren oder ihn mindestens weiterzugeben (THROW/RAISE).

Kann man ausschließlich die integrierten SQL Server/DBMS-Logs verwenden, um alle Fehler in Benutzerprozeduren zu identifizieren?

Teilweise. Viele Fehler erscheinen nicht in den Serverprotokollen, wenn sie im Anwendungs- oder Prozedurbereich „abgefangen“ und behandelt werden. Für die Geschäftslogik ist es nützlich, ein eigenes Ereignisprotokoll mit Details zu führen.

Muss man TRY/CATCH (oder EXCEPTION) verwenden, wenn die Prozedur nur einfache DML-Operationen verwendet?

Ja, wenn die Prozedur wichtige Daten beeinflusst, in kritischen Ketten beteiligt ist und außergewöhnliche Situationen protokollieren muss. Selbst „sichere“ Operationen können aufgrund externer Einschränkungen (Eindeutigkeit, FOREIGN KEY, Deadlocks usw.) zu Fehlern führen.

Typische Fehler und Anti-Muster

Kein separates Fehlerprotokoll auf Anwendungsebene führen.
Den Fehler abfangen, aber die Informationen nicht an den Benutzer/Administrator weitergeben.
Umfangreiche Fehlerbehandlungsblöcke ohne Vorlagen schreiben — dies verringert die Lesbarkeit.

Beispiel aus dem Leben

Negativer Fall

Im Projekt werden Fehler nicht protokolliert, sondern nur dem Benutzer angezeigt. Bei einem massiven Ausfall sucht der Administrator stundenlang nach dem „unsichtbaren“ Problem.

Vorteile:

Einfache Lösung, weniger Code.

Nachteile:

Diagnose ist unmöglich.
Keine Grundlage für Audits und Datenqualitätsanalysen.

Positiver Fall

Jeder kritische Fehler wird in einer Protokolltabelle mit Details (Zeit, Prozedur, Parameter, Fehlercode) festgehalten, und auf ihn wird in einem Systemticket verwiesen.