Risposta.

Qualsiasi soluzione industriale in SQL richiede un'architettura efficace per la gestione degli errori. Senza il logging e una gestione attenta delle eccezioni, non è possibile il debug di processi complessi, specialmente in stored procedure e script batch.

Storia della domanda: SQL standard consente una minima gestione degli errori (ad esempio, RETURN e interrompere l'elaborazione). Le estensioni moderne (T-SQL, PL/pgSQL, PL/SQL, ecc.) forniscono costrutti completi per la gestione degli errori (TRY/CATCH, EXCEPTION).

Problema: Senza una gestione esplicita degli errori, si "affondano", e l'amministratore ha difficoltà a determinare la causa del guasto, specialmente durante modifiche di massa o interazioni con sistemi esterni. Spesso sorge la necessità di registrare gli errori in una tabella separata per analisi successive.

Soluzione: Utilizza l'arsenale di TRY/CATCH (T-SQL) o EXCEPTION (PL/pgSQL), oltre a tabelle di logging dedicate. Non dimenticare di inviare informazioni diagnostiche (codice errore, messaggio errore, parametri della query e ora) nel log.

Esempio di codice (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
        -- Logica di business
        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

Esempio di codice (PL/pgSQL, PostgreSQL):

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

Caratteristiche chiave:

Accesso immediato ai dettagli del guasto per il debug.
Completamente tracciabile attraverso tutte le fasi del processo.
Non interrompere l'esecuzione senza un ritorno esplicito e una raccolta centralizzata del log.

Domande trappola.

È sufficiente intercettare l'errore e terminare l'esecuzione della procedura senza fornire informazioni all'esterno?

No. Senza un logging esplicito o una propagazione dell'errore, non è possibile catturare e analizzare le cause del guasto. È importante dettagliare l'errore nel log o almeno propagare ulteriormente (THROW/RAISE).

È possibile utilizzare esclusivamente i log integrati di SQL Server/DBMS per identificare tutti gli errori nelle procedure utente?

Parzialmente. Molti errori non vengono registrati nei log del server, se vengono "catturati" e gestiti nell'applicazione o nelle procedure. È utile mantenere il proprio log degli eventi con dettagli per la logica di business.

È necessario utilizzare TRY/CATCH (o EXCEPTION) se nella procedura si usano solo operazioni DML semplici?

Necessario, se la procedura influisce su dati importanti, parte di catene critiche e deve registrare situazioni anomale. Anche operazioni "sicure" possono generare errori a causa di vincoli esterni (unicità, FOREIGN KEY, deadlock, ecc.).

Errori comuni e anti-pattern

Non mantenere un log degli errori separato a livello applicativo.
Intercettare l'errore, ma non fornire informazioni all'utente/amministratore.
Scrivere blocchi di gestione ingombranti senza modelli — riduce la leggibilità.

Esempio dalla vita reale

Caso negativo

Nel progetto gli errori non vengono registrati, solo visualizzati all'utente. Durante un guasto di massa, l'amministratore cerca per ore un problema "invisibile".

Pro:

Soluzione semplice, meno codice.

Contro:

Diagnosi impossibile.
Nessuna base per audit e analisi della qualità dei dati.

Caso positivo

Qualsiasi errore critico viene registrato in una tabella di log con dettagli (ora, procedura, parametri, codice errore), e su di esso si fa riferimento in un ticket di sistema.