Question

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

e.g。

- 使用错误代码

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

e.g。 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

后者似乎产生了更易维护的代码

Answer 1

关于编码风格，这可能是一个宗教问题。返回代码和异常之间的主要区别在于异常将继续传递给调用链。

通常，在我编写的代码中，我使用返回值将存储过程的状态作为“应用程序错误”返回。与您的示例一样，0表示成功，其他任何表示失败。每当我在实际代码中调用存储过程时，我都会检查返回值以及可能出现的任何新错误。顺便说一句，在SQL Server中，您无法使用“@retval＆lt;＆gt; 0”检查失败，因为存储过程可以返回NULL。

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

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

t-sql返回错误代码与RaiseError

1 个答案: