当前位置：文江博客话题详情

存储过程 - 将消息传递回用户应用程序的最佳方式

发布于 2024-07-06 05:35:59 字数 177 浏览 3 评论 0原文

我想知道人们如何看待在存储过程中使用 RAISERROR 将用户消息（即业务相关消息，而不是错误消息）传回应用程序。

我公司的一些高级开发人员一直在使用这种方法，并在 C# 代码中捕获 SqlException 来获取消息并将其显示给用户。我对这种方法不满意，想知道其他人如何处理来自存储过程的这些类型的用户消息。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

痴者 2024-07-13 05:35:59

像这样使用 RAISERROR 确实不是一个好主意。这就像使用异常作为流程控制逻辑一样，通常不受欢迎。

为什么不使用 OUT 参数来代替呢？这正是他们的目的。我想不出不支持 OUT 参数的数据库或客户端 API。

回复收藏 0 原文

我们的影子 2024-07-13 05:35:59

我已经这样做了，但它通常是为了传递业务“错误”消息，本质上必须有一个数据配置，无论出于何种原因都无法使用标准 FK 约束来强制执行。

如果它们实际上是“错误”，我对此没有太大问题。如果它插入一条记录并使用 RAISERROR 抛出（“您已成功注册 XYZ！”），那么您就会遇到问题。如果是这样的话，我可能会提出一个使用 out 参数的团队/部门/公司开发标准。

回复收藏 0 原文

不再见 2024-07-13 05:35:59

我会尝试避免让我的存储过程返回业务相关消息，因为根据定义，这些类型的消息可能应该在业务逻辑层中处理/生成。

例外情况应该是例外的（罕见的）。我只会在错误时使用 RAISEERROR （就像我尝试导入所有这些数据，但其中一行有愚蠢的数据，所以我回滚了事务）。您还需要非常小心所引发的错误的严重性，这可能会对错误的传播方式以及连接发生的情况产生巨大影响。

如果这还不够，请尝试使用返回值或输出变量。

回复收藏 0 原文

泪冰清 2024-07-13 05:35:59

仅当情况异常并且您没有处理逻辑时才应抛出异常。引发和捕获异常的成本也很高。

避免使用异常，除非

情况非常特殊
您没有针对异常情况的处理逻辑

使用输出参数或返回多个结果集来传递来自存储过程的信息。

回复收藏 0 原文

回眸一遍 2024-07-13 05:35:59

让你的存储过程返回2组数据。第一个可以包含实际返回的数据，然后第二个可以返回文本消息。然后，您的应用程序代码可以在需要的地方使用数据，然后显示返回的任何消息。

回复收藏 0 原文

溺渁∝ 2024-07-13 05:35:59

回答这么老的问题是不是不太好？任何人......

对于您的日常状态消息，这将是一件坏事，我几乎同意上面的每个答案。然而，我发现它非常有效地用于显示长批次的进度。请参阅从批处理和存储过程获取反馈/进度（Jens K 的示例）。你必须有一个非常核心的理由才能这样做，但是当你需要它时，你需要它，而且它非常棒。

回复收藏 0 原文

百变从容 2024-07-13 05:35:59

当错误发生时，我们会引发错误，并在输出变量或返回值中返回状态信息。

回复收藏 0 原文

戒ㄋ 2024-07-13 05:35:59

您应该使用 SQL 存储过程输出参数。

来自 http://msdn.microsoft.com/en-us/library/ms378108 .aspx：

CREATE PROCEDURE GetImmediateManager
   @employeeID INT,
   @msg varchar(50) OUTPUT
AS
BEGIN
   SELECT ManagerID 
   FROM HumanResources.Employee 
   WHERE EmployeeID = @employeeID

   SELECT @msg = 'here is my message'
END

You should be using SQL stored procedure output parameters.

From http://msdn.microsoft.com/en-us/library/ms378108.aspx:

CREATE PROCEDURE GetImmediateManager
   @employeeID INT,
   @msg varchar(50) OUTPUT
AS
BEGIN
   SELECT ManagerID 
   FROM HumanResources.Employee 
   WHERE EmployeeID = @employeeID

   SELECT @msg = 'here is my message'
END

回复收藏 0 原文

匿名的好友 2024-07-13 05:35:59

如果不能及早检查/捕获它，可能很难做其他事情。

我必须在我编写的过程中编写一个 raiseerror 并将其用作插入/更新表的约束，因为它是数据的“最后一站”，我必须在那里检查它。

我认为一般来说，如果您从数据库返回错误..这是一个痛苦的事情，并且很难在不付出很大努力的情况下向用户提供“好的”反馈，但有时您只是不知道，直到您插入/更新：P

回复收藏 0 原文

得不到的就毁灭 2024-07-13 05:35:59

我亵渎的 2 美分：

基于文本的消息在网络上运行得非常好，例如 HTTP。创建、发送和调试系统很容易，其中消息传递以人类可读的文本完成。

因此，SQL Server 层与其上层之间的消息传递可能也是同样的情况。使用文本作为消息传递的一部分可能会让您的开发更加敏捷，调试也更加容易。也许高级开发人员很务实，您也许应该愿意抛开先入为主的正确性观念。

根据设计选择本身的优点来争论，而不是基于正确性的概念。（软件开发也有时尚）

回复收藏 0 原文

迟到的我 2024-07-13 05:35:59

我将使用存储过程中的 RETURN 值，如下所示：

CREATE PROCEDURE checkReturnValue
AS
BEGIN
    DECLARE @err AS INT
    SET @err = 0

    IF (rand() < 0.5)
    BEGIN
        SET @err = 1
    END

    SELECT * FROM table

    PRINT @err

    RETURN @err
END

检查调用存储过程的应用程序中的 RETURN 值。

I'd use the RETURN value from the stored procedure, like this:

CREATE PROCEDURE checkReturnValue
AS
BEGIN
    DECLARE @err AS INT
    SET @err = 0

    IF (rand() < 0.5)
    BEGIN
        SET @err = 1
    END

    SELECT * FROM table

    PRINT @err

    RETURN @err
END

Check the RETURN value in your application calling the stored procedure.

回复收藏 0 原文

悸初 2024-07-13 05:35:59

仅当“业务”错误消息是数据库错误消息时，即违反了为满足数据库级别的基本低级业务需求而设置的数据库约束。

它不应该用于高级业务逻辑，这应该避免在数据库层中。数据库层总是变化最慢的，因此只有非常缓慢变化和不变的业务逻辑才应该存在。

因此，对于不活跃/禁用客户的订单消息，可能是“是”，但对于 90 天内有余额的客户的订单则不然。第一条规则可能是永久性的，第二条规则可能是可配置的，每月都会受到业务突发奇想的影响。

回复收藏 0 原文

仙女 2024-07-13 05:35:59

我使用 raiseerror 从多个嵌套存储过程的深处返回，但存储过程的最后一层总是在引发到调用语言（在我们的例子中是通过 JDBC 的 Java）之前捕获异常。最外层的存储过程 catch 被转换为 XML 消息以传输到 JDBC 调用，并且根据我们的约定，根元素必须包含反馈属性。反馈属性的值始终具有 ok、alert 或 error 装饰器。好的意味着继续，这里没什么可看的。警报意味着继续，但向用户显示其余的反馈。错误意味着弃踢，请致电服务台。

回复收藏 0 原文