应该用什么策略来处理SQL异常？ [英] What should be the strategy to handle the sql exceptions?

问题描述

我有一个多层应用程序。 DAL - > BAL - >业务网关 - >用户界面。 如果在DAL出现外键或唯一约束的例外，我们应该如何识别哪些例外的是这个，什么错误信息显示给用户。我们应该用错误编号，以确定这一点。

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.

第二个问题：我们应该如何propogate此错误UI。我们正在考虑抛出此异常BAL和BAL将封装错误并返回一个响应（不除外）到用户界面。是不是正确的做法。

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.

推荐答案

DAL例外情况应进行处理，并重新抛出（自定义例外）你BAL。你应该序列，并通过您正在使用的通信信道发送到您的用户界面。

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.

您并不需要表现出精确的错误给用户或错误的数字，因为这将形成不好的用户体验。你可以告诉他们，你不能在数据库执行该操作。你可以在一些日志文件或Windows事件日志中记录的详细信息。

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.

编辑： SQLEXCEPTION有错误code，你可以检查在DAL再扔根据一个特定的异常。你的DAL抽象了SQL Server作为后台存储，因此SQLExceptions的不应该将DAL外泄漏。因此，在DAL检查错误code和抛出一个特定的异常。

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.

这篇关于应该用什么策略来处理SQL异常？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！