Antwoord.

Elke industriële oplossing in SQL vereist een doordachte architectuur voor foutafhandeling. Zonder logging en zorgvuldige exception handling is het onmogelijk om complexe processen te debuggen, vooral in opgeslagen procedures en batchscripts.

Achtergrond van de vraag: Standaard SQL staat minimale foutafhandeling toe (bijvoorbeeld RETURN en stopzetten van de verwerking). Moderne extensies (T-SQL, PL/pgSQL, PL/SQL, enz.) bieden volledige constructies voor foutafhandeling (TRY/CATCH, EXCEPTION).

Probleem: Zonder expliciete foutafhandeling "verdwijnen" fouten, en is het moeilijk voor de beheerder om de oorzaak van de storing vast te stellen — vooral bij massale wijzigingen of interactie met externe systemen. Vaak ontstaat de behoefte om fouten in een aparte tabel te loggen voor latere analyse.

Oplossing: Gebruik de toolkit van TRY/CATCH (T-SQL) of EXCEPTION (PL/pgSQL), evenals uw eigen logtabellen. Vergeet niet om diagnostische informatie (foutcode, fouttekst, requestparameters en tijd) naar de log te sturen.

Voorbeeldcode (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
        -- Bedrijfslogica
        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

Voorbeeldcode (PL/pgSQL, PostgreSQL):

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

Belangrijkste kenmerken:

Directe toegang tot de details van fouten voor debugging.
Volledige traceerbaarheid van alle fasen van het proces.
Stop de uitvoering niet zonder expliciete terugkeer en centrale logging.

Misleidende vragen.

Is het voldoende om een fout te vangen en de uitvoering van de procedure te beëindigen zonder informatie naar buiten te brengen?

Nee. Zonder expliciete logging of het doorgeven van de fout is het onmogelijk om de oorzaken van de storing te ontdekken en te analyseren. Het is belangrijk om de fout in de log te detailleren of in ieder geval verder te geven (THROW/RAISE).

Kun je uitsluitend de ingebouwde SQL Server/DBMS-logs gebruiken om alle fouten in gebruikersprocedures te identificeren?

Deels. Veel fouten komen niet in de serverlogs terecht als ze "gevangen" en afgehandeld worden in de applicatie of in de procedures. Voor bedrijfslogica is het nuttig om een eigen gebeurtenislog bij te houden met details.

Moet je TRY/CATCH (of EXCEPTION) gebruiken als er in de procedure alleen eenvoudige DML-operaties worden uitgevoerd?

Ja, als de procedure invloed heeft op belangrijke gegevens, deelneemt aan kritieke ketens en niet-normale situaties moet registreren. Zelfs "veilige" bewerkingen kunnen fouten veroorzaken door externe beperkingen (uniekheid, FOREIGN KEY, deadlocks, enz.).

Typische fouten en anti-patronen

Geen aparte foutlog bijhouden op applicatieniveau.
Een fout afvangen, maar de informatie niet aan de gebruiker/beheerder doorgeven.
Ongemakkelijke verwerkingsblokken schrijven zonder sjablonen — dit vermindert de leesbaarheid.

Voorbeeld uit de praktijk

Negatieve case

In het project worden fouten niet gelogd, alleen aan de gebruiker weergegeven. Bij een massale storing zoekt de beheerder uren naar een "onzichtbaar" probleem.

Voordelen:

Eenvoudige oplossing, minder code.

Nadelen:

Diagnose is niet mogelijk.
Geen basis voor auditing en kwaliteitsanalyse van gegevens.

Positieve case

Elke kritische fout wordt geregistreerd in een logtabel met details (tijd, procedure, parameters, foutcode), en hier wordt naar verwezen door een ticket in het systeem.