8

嗨，我正在编写一个存储过程，它将按小时计划执行一批作业，我正在尝试决定是返回错误还是引发错误。假设我将记录每个作业中的错误，这将导致更好的性能和可维护性？

例如

--带有错误代码

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 中，您不能使用“@retval <> 0”检查失败，因为存储过程可以返回 NULL。

当然，异常/数据库错误仍然可能发生。这个想法是，当识别出异常时，它会被记录和处理。系统“错误”变成了应用程序错误。

我遇到的一个问题是与 SQL Server 代理的交互。为此，您希望引发错误以“分叉”到错误处理步骤。这很容易在作业步骤中完成，方法是查看返回值然后生成错误。

于 2013-01-02T15:29:12.100 回答