Odpowiedź.

Obsługa błędów i organizacja logowania w SQL zyskały szczególną popularność wraz z rozwojem złożonych procesów biznesowych, gdy zaczęło być ważne nie tylko zatrzymywanie wykonywania po wystąpieniu błędu, ale też rejestrowanie faktu awarii i, w miarę możliwości, kontynuowanie pracy. Początkowo SQL nie miał rozwiniętych środków try-catch, a każda SGBD oferowała swoje mechanizmy.

Historia pytania:

Wczesne wersje standardów SQL nie miały wbudowanych operatorów do przechwytywania błędów w procedurach. Później producenci zaczęli wprowadzać konstrukcje, takie jak TRY...CATCH w Microsoft SQL Server, czy HANDLER w MySQL, co pozwalało na bardziej elastyczne kontrolowanie procesu roboczego bezpośrednio na poziomie Bazy Danych.

Problem:

Błędy mogą występować zarówno wskutek niepoprawnych danych, jak i z przyczyn systemowych. Jeśli w procedurze składowanej nie zrealizowano przechwytywania i rejestracji błędów, debugowanie i utrzymanie stają się niezwykle trudne. Ponadto, należy umieć rozróżnić błędy krytyczne i obsługiwane, aby nie przerywać wykonywania operacji biznesowych tam, gdzie nie jest to konieczne.

Rozwiązanie:

W nowoczesnych systemach należy wprowadzić konstrukcje do zbierania i logowania błędów. Należy tworzyć oddzielne tabele logów, stosować TRY...CATCH (SQL Server) lub DECLARE ... HANDLER (MySQL), zachowywać szczegółowe informacje o wyjątkach, aby później analizować przyczyny awarii.

Przykład kodu (SQL Server):

CREATE PROCEDURE dbo.UpdateCustomer
  @CustomerID INT,
  @NewName NVARCHAR(100)
AS
BEGIN
  BEGIN TRY
    UPDATE Customers SET Name = @NewName WHERE CustomerID = @CustomerID;
  END TRY
  BEGIN CATCH
    INSERT INTO ErrorLog (ErrorMessage, ErrorSeverity, ErrorTime)
    VALUES (ERROR_MESSAGE(), ERROR_SEVERITY(), GETDATE());
    THROW;
  END CATCH
END;

Kluczowe cechy:

Użycie TRY...CATCH pozwala na izolowanie potencjalnie niebezpiecznego kodu.
Wstawianie błędów do tabeli logów z maksymalną szczegółowością.
Throw/Error raising dla prawidłowego zakończenia procedury i przekazania informacji do warstwy wywołującej.

W pytaniach z podtekstem.

Czy wszystkie typy błędów można złapać wewnątrz bloku TRY...CATCH (lub przez handler)?

Nie, nie wszystkie błędy, np. poważne awarie serwera, mogą być przechwycone. Błędy typu „Attention”, czy awaria połączenia, wykraczają poza granice obsługi transakcyjnej.

Co się stanie z niezobowiązującymi zmianami w procedurze przy błędzie, jeżeli nie używa się transakcji?

Zmiany będą częściowo zrealizowane, część aktualizacji wejdzie do bazy, a część może zostać utracona. Aby uniknąć niespójności, zaleca się zawsze korzystać z transakcji.

BEGIN TRY
  BEGIN TRANSACTION;
  --...kod
  COMMIT;
END TRY
BEGIN CATCH
  ROLLBACK;
END CATCH

Czy można używać INSERT EXEC bezpośrednio z bloku CATCH, aby zapisać błąd z innego kontekstu?

Nie zawsze: INSERT EXEC jest zabroniony w niektórych kontekstach (np. jeśli już istnieje aktywna transakcja), co może wywołać błędy drugiego poziomu. Lepiej jest zbierać szczegóły błędu lokalnie i później zapisywać je pojedynczym INSERT.

Typowe błędy i antywzorce

Brak logowania błędów.
Ignorowanie TRANSACTION, co prowadzi do zerwania danych.
Logowanie tylko tekstów, bez kodów błędów oraz czasu/kodu użytkownika.

Przykład z życia

Negatywny przypadek

Klient zrealizował logikę tylko przez RAISERROR bez logowania, dlatego błędy nie były zapisywane i analizowane.

Zalety:

Mniej kodu.

Wady:

Brak możliwości zrozumienia przyczyny awarii, analiza problemów w produkcji niemożliwa.

Pozytywny przypadek

Użycie TRY...CATCH oraz tabeli ErrorLog, rejestracja czasu, kodu błędu, użytkownika, tekstu i śladu.