8

こんにちは私は1時間ごとのスケジュールでジョブのバッチを実行するストアドプロシージャを書いています。エラーを返すか、エラーを発生させるかを決定しようとしています。パフォーマンスと保守性の向上につながる各ジョブ内のエラーをログに記録すると仮定しますか？

例えば

-エラーコード付き

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

例：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

後者はより保守しやすいコードを生成するようです

4

1 に答える 1

4

コーディングスタイルに関しては、これは宗教的な問題かもしれません。戻りコードと例外の主な違いは、例外が引き続き呼び出しのチェーンに渡されることです。

一般に、私が作成するコードでは、戻り値を使用して、ストアドプロシージャのステータスを「アプリケーションエラー」として返します。あなたの例のように、0は成功を意味し、それ以外は失敗を意味します。実際のコードでストアドプロシージャを呼び出すときはいつでも、戻り値と発生する可能性のある新しいエラーをチェックします。ちなみに、SQL Serverでは、ストアドプロシージャがNULLを返す可能性があるため、「@ retval<>0」で失敗をチェックすることはできません。

もちろん、例外/データベースエラーは引き続き発生する可能性があります。例外が認識されると、ログに記録されて処理されるという考え方です。システムの「エラー」はアプリケーションエラーに変わります。

私が遭遇した問題の1つは、SQLServerエージェントとの相互作用です。このために、エラー処理ステップに「フォーク」するエラーを発生させる必要があります。これは、戻り値を確認してエラーを生成することにより、ジョブステップ内で簡単に実行できます。

于 2013-01-02T15:29:12.100 に答える