处理sql异常的策略应该是什么?

发布于 2024-12-10 07:30:09 字数 192 浏览 0 评论 0原文

我有一个多层应用程序。达尔->巴尔->业务网关->UI。 如果DAL发生外键或唯一约束异常,我们应该如何识别这是哪个异常以及向用户显示什么错误消息。我们应该使用错误号来识别这一点吗?

第二个问题:我们应该如何将此错误传播给 UI。我们正在考虑将此异常抛出给 BAL,BAL 会封装错误并向 UI 返回响应(不是异常)。这是正确的方法吗?

I have a multi-tier application. DAL -> BAL -> Business Gateway ->UI.
If a foreign key or unique constraint exception occurs at DAL, How should we recognize which exception is this and what error message to show the user. Should we use error number to identify this.

Second question : How should we propogate this error to UI. We are thinking to throw this exception to BAL and BAL would encapsulate the error and return a response(not exception) to UI. Is it the right approach.

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

扫码二维码加入Web技术交流群

发布评论

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

评论(1

乱了心跳 2024-12-17 07:30:09

DAL 异常应该由 BAL 处理并重新抛出(作为自定义异常)。您应该将其序列化并通过您正在使用的通信通道发送到您的 UI。

您不需要向用户显示确切的错误或错误号,因为这会形成不良的用户体验。你可以告诉他们你无法在数据库中执行该操作。您可以在某些日志文件或 Windows 事件日志中记录详细信息。

编辑: SqlException 有错误代码,您可以在 DAL 中检查该错误代码,然后根据该错误代码引发特定异常。您的 DAL 将 SQL Server 抽象为后端存储,因此 SqlException 不应泄漏到 DAL 之外。因此,在 DAL 中检查 ErrorCode 并抛出特定异常。

DAL exceptions should be handled and rethrown (as custom exceptions) by your BAL. Which you should serialize and send over to your UI via communication channel that you're using.

You don't need to show exact error to the user or error number because that would form bad user experience. You can just tell them that you could not perform the operation in db. You can log the details in some log file or windows event log.

EDIT: SqlException has error code which you can check in DAL and then throw a specific exception based on that. Your DAL abstracts out SQL Server as backend store and therefore SqlExceptions should not leak outside your DAL. So within DAL check the ErrorCode and throw a specific exception.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文