t-sql Powrót Kody błędów vs RaiseError

Question

Witam Piszę procedurę przechowywaną, która będzie wykonywała partię zadań w harmonogramie godzinowym i próbuję zdecydować, czy zwrócić błędy lub je podnieść. Zakładając, że rejestrowałbym błędy w każdym zadaniu, które prowadziłyby do lepszej wydajności i łatwości konserwacji?

np.

-with kody błędu

CREATE PROCEDURE Job1 
AS 
BEGIN 

    BEGIN TRY 
     --Do some work 
    END TRY 
    BEGIN CATCH 
     --log error 
     RETURN 1; --Return 1 for error 
    END CATCH 
    RETURN 0; 

END 

CREATE PROCEDURE USP_BatchJob 
AS 
BEGIN 
    BEGIN TRANSACTION; 

    DECLARE @Error INT; 
    EXEC @Error = Job1; 
    IF @Error <> 0 
     GOTO ErrorHandling; 

    EXEC @Error = Job1; 
    IF @Error <> 0 
     GOTO ErrorHandling; 

    IF @@TRANCOUNT > 0 
     COMMIT TRANSACTION; 

    RETURN; 

ErrorHandling: 
    IF @@TRANCOUNT > 0 
     ROLLBACK; 
END 

np RaiseError

CREATE PROCEDURE Job1 
AS 
BEGIN 

    BEGIN TRY 
     --Do some work 
    END TRY 
    BEGIN CATCH 
     --log error 
     RAISERROR(ERROR_MESSAGE(), ERROR_SEVERITY(), ERROR_STATE()); 
    END CATCH 

END 

CREATE PROCEDURE USP_BatchJob 
AS 
BEGIN 
    BEGIN TRANSACTION 
    BEGIN TRY 

    EXEC Job1; 

    EXEC Job1; 

    END TRY 
    BEGIN CATCH 
     IF @@TRANCOUNT > 0 
      ROLLBACK; 
    END CATCH 

    IF @@TRANCOUNT > 0 
     COMMIT TRANSACTION; 

END 

Ten ostatni wydaje się produkować kod bardziej linkujących

Answer 1

Będąc o styl kodowania, może to być problem religijny. Główną różnicą między kodem powrotu i wyjątkiem jest to, że wyjątek będzie nadal przekazywany do łańcucha wywołań.

Ogólnie w kodzie, który piszę, używam zwracanych wartości, aby zwrócić status procedury składowanej jako "błąd aplikacji". Podobnie jak w twoim przykładzie, 0 oznacza sukces, a cokolwiek innego oznacza porażkę. Ilekroć wywołuję procedurę przechowywaną w kodzie rzeczywistym, mam kontrolę wartości zwracanej, a także wszelkich nowych błędów, które mogą się pojawić. Nawiasem mówiąc, w SQL Server nie można sprawdzić, czy nie powiodło się z "@retval <> 0", ponieważ procedury przechowywane mogą zwracać NULL.

Oczywiście, błędy wyjątków/bazy danych mogą nadal występować. Chodzi o to, że po rozpoznaniu wyjątku jest on rejestrowany i obsługiwany. System "błąd" zamienia się w błąd aplikacji.

Jedną z napotkanych problemów jest interakcja z programem SQL Server Agent. W tym celu chcesz zgłosić błąd "rozwidlenia" do kroku obsługi błędów. Można to łatwo zrobić w ramach etapu zadania, patrząc na wartość zwracaną, a następnie generując błąd.