.NET异常处理表中的查找

Question

我的经理设计了一个与此类似的表格

[异常]
PK | ExceptionId
ExceptionCode varchar（100）
ExceptionDesc varchar（255）
ExceptionMSG varchar（255）

我正在使用ASP.NET Webforms并使用存储过程/ ADO.NET进行DataAccess。 现在，他不希望我在存储过程或后面的代码中进行硬编码验证，而是捕获约束异常消息并在数据库中查找相同的错误消息并查找我们想要显示的消息。我想知道他的设计是否有用，或者我应该向他解释这里出了什么问题。

你觉得怎么样？

Answer 1

因此，方法没有任何问题 - 实际的错误消息字符串将存储在某些商店而不是硬编码中。这里的选择商店是一个数据库。除了我建议的东西之外，这种方法应该有效：

1. 应该缓存错误消息 - 我更喜欢在app start中缓存所有消息，而不是按需缓存。
2. 您可能需要对处理应用启动的一些消息进行硬编码（例如，无效的数据库连接字符串等）
3. 通常，异常应使用某些外观（如IMessageProvider）查找消息字符串。在您的情况下，IMessageProvider实现将使用在应用程序启动时从数据库填充的缓存（字典）。您可以轻松地将此实现与其他内容交换（可能从资源文件加载等）。您可以考虑使用IOC /依赖注入为异常对象提供适当的消息提供程序实现。
4. 典型的消息查找实现应该具有故障安全机制 - 例如，如果错误代码不存在，那么它可以使用硬编码字符串，例如“发生了一些错误（代码：xxxx），请联系你的管理员“。理想情况下，不希望用户在实时系统中看到此消息。

Answer 2

在我看来，在数据库中查找异常消息似乎有点傻，考虑到异常是否与数据库连接相关，你真的无法查找消息哈哈。在Web服务器上可能有一个可以更改的配置文件（作为资源）对我来说更有意义，而不是连接到数据库的麻烦。然而，在我所做的所有ASP站点中，开发人员都会在他们抛出的异常中做出有意义的消息，尤其是验证。

我可以看到对可变信息的渴望;但是，我认为数据库可能有点矫枉过正。我可能是错的......我可能没有遇到过最有意义的情况。但是，如果你的经理绝对坚持这一点，那么我想你必须让它发挥作用。我想只是对连接相关的异常的情况感到厌倦。我希望这很有帮助。