有没有办法在违反约束时给出用户友好的错误消息

Question

假设我有列 Gender 和约束 CHECK( Gender IN ('F', 'M', 'OTHER'))。
如果我不小心忘记在客户端处理这个问题，用户将看到类似
ORA-02290: 违反检查约束 (SYS_C099871244)
这对用户和维护或调试的开发人员来说都不是很有帮助

有没有办法提供开发人员定义的消息，例如（伪）Java的
assert Gender IN (0,1):'Gender must be F or M'

我能想到的唯一方法是将约束移至 BEFORE UPDATE OR INSERT 触发器，并在失败时执行 Raise_Application_Error （代码，my_message）。但我不喜欢它

编辑 具体原因列表，如评论中
1. 我真的很喜欢让逻辑尽可能接近数据
2. 对于最终用户而言，Raise_Application_Error 消息与应用程序消息无法区分
3.即使绕过应用程序访问数据，开发人员也会看到不错的消息
4.将约束移动到触发器很丑陋（是吗？），所以我必须找到与 Raise_Application_Error 不同的东西

EDIT2 1.5 年后，在我离开与数据库相关的工作后，我终于意识到，我真正不喜欢这个 - 代码重复 。我必须在服务器和客户端上重复完全相同的逻辑。最有可能的是，用两种不同的语言。并使它们保持同步。这太丑了。

尽管答案清楚地表明，我对此无能为力。所以现在是我成为好公民并最终接受答案的时候了（抱歉，只是忘记了这一点）。

Answer 1

约束是数据库用来保护自己免受错误应用程序，的影响，而不是来自用户的影响。

这意味着应用程序应该捕获约束违规，并可能进行清理以呈现给用户。我认为没有这样做的应用程序在某种程度上是有缺陷的。

我说“可能”是因为您的应用程序（至少对于这种情况）永远不会看到这种情况发生。几乎可以肯定，它应该使用下拉式有限选择控件来实现类似的功能。如果它使用组合框或（震惊，恐怖）自由格式的文本输入字段，则需要重新定义。

这意味着违规永远不会发生，除非应用程序和约束在某个时刻不同步。但是，早在客户接触您的应用程序之前，就应该在测试中发现这一点。

---

为了回答您的实际问题，Oracle 发出的有关约束违规的消息无法更改。您能做的最好的事情就是明智地命名您的约束，以便最终用户能够理解。

但我仍然认为向用户呈现问题是应用程序层的责任，而不是数据库层的责任。

Answer 2

如果您正在寻找一种方法来告诉 Oracle 始终将异常消息“ORA-02290：违反检查约束 (SYS_C099871244)”替换为另一条消息（例如“ORA-20001：性别必须是 F 或 M”），那么答案是：不，这是不可能的。

您可以做的是提供一个可供开发人员在其代码中使用的解决方案，如下所示：

...
begin
    insert into emp (empno, gender) values (p_empno, p_gender);
exception
    when others then
       error_pkg.handle_exception;
end;

error_pkg.handle_exception 过程将解析 Oracle 异常消息并提取约束的名称（如果是）约束违规）并在交叉引用表中查找该约束名称以获取所需的消息，然后使用 raise_application_error 使用新消息重新引发异常。

我想Oracle可以提供像这样的包和表作为标准，但也许由于在实践中系统中的错误处理有许多不同的要求，所以它通常被认为不够有用。

Answer 3

简而言之：
据我所知，没有办法捕获用于自定义处理的 Oracle 错误。但我认为无论如何你都不应该尝试这样做。

---

长版：
你的理由背后的意图是好的，但是......

我真的很喜欢让逻辑尽可能接近数据

逻辑应该尽可能接近数据，这是事实；但这不符合条件 - 这不是逻辑，这是识别已定义逻辑异常的代码的表示，并且表示不应与数据或逻辑层混合（错误消息的范围涵盖从客户端到服务器端的每个部分；还要考虑翻译、一致更新、更轻松的消息管理和概述等...）

对于最终用户，Raise_Application_Error 消息是
与应用程序无法区分
留言

True，但反之亦然，因此不是特别相关 - 如果您有数据库错误代码、应用程序错误代码的中央存储库，并且错误处理将对其进行处理，那么哪一层出现错误是不相关的（对于最终用户）消息。此外，从长远来看，尚不清楚它是否会节省您的任何工作。

即使访问数据绕过，开发人员也会看到不错的消息
应用

确实如此，对于直接访问数据库的开发人员来说，会有更好的错误消息。这里仍然有一些评论适用 - 在复杂的系统中，不应允许绕过应用程序层（即使对于开发人员也是如此）；如果允许的话，您会期望开发人员知道在哪里从约束名称查找错误消息（错误代码和消息的中央存储库应该/将维护在同一个数据库中）

将约束移动到触发器是丑陋的
（是吗？），所以我必须找到一些东西
与 Raise_Application_Error 不同

它在某种意义上是丑陋的，因为它是表现形式，不应该出现在 DDL 中。此外，如果通过触发器完成，它会导致不合理的（？）性能损失（不确定它有多大，也不知道它可以完成得有多优雅）。

注意：总而言之，我确实同意能够挂钩 DBMS 错误处理将是一个很好的功能。

然而，错误处理和错误消息处理具有以下属性

• 需要可维护（理论上，可以通过在信息模式中存储自定义错误消息来干净地完成此操作，但 SQL 标准没有指定这一点，因此这纯粹是理论评论 - 实际上为此，您必须拥有自己的表）

，更重要的是，

• 错误消息处理是上下文敏感的（并且错误处理程序将从数据客户端的角度获得最多的信息 - 有时相同错误代码可能需要不同的呈现方式、不同的消息）

Answer 4

无论约束是向客户端提出还是记录在文件中以供支持人员进行（潜在）分析，您都应该获得更有用的消息。

如果你命名你的约束，它会变得更有帮助。

我会去做类似的事情

ALTER TABLE blah ADD CONSTRAINT blah_gender_ck CHECK ( Gender IN ('F', 'M', 'OTHER'));