三层架构中的错误处理
如何优雅地实现错误处理？ 例如，我的数据访问层可能会引发两种类型的错误： 1) 未经授权的访问，在这种情况下，页面应隐藏所有内容并仅显示错误消息 2）错误通知用户数据库中已经存在类似的内容（例如，名称不唯一），在这种情况下我不想隐藏所有内容。
编辑：
由于这里的一些评论，我设计应该创建派生的专门异常类型，例如 NotAuthorizedException、DuplicateException 等......这一切都很好，但是我可以看到两个潜在的问题：
1）每个存储proc 有一个返回字段 p_error，其中包含错误消息。 从数据库获取数据后，我需要检查此字段以查看返回的错误类型，以便我可以抛出适当的异常。 所以，我仍然需要在某处存储我的错误类型/错误消息......换句话说，我如何应该向用户发送确切的消息（在某些时候我需要）而不首先检查 p_error 字段。 这让我回到错误对象。 任何人？
2）这可能会变成一场噩梦，其中异常的数量等于错误消息类型的数量。
我在这里错过了什么吗？
非常感谢大家！
How do I implement error handling elegantly? For example, my data access layer can potentially throw 2 types of errors:
1) not authorized access, in which case the page should hide everything and just show the error message
2) errors that inform the user that something like this already exists in the database (say name not unique - for example), and in this case I wouldn't want to hide everything.
EDITED:
As a result of some comments here I devised that I should create derived specialized exception types, such as NotAuthorizedException, DuplicateException, etc etc.... it's all fine and dandy, however I can see 2 problems potentially:
1) Every stored proc has a return field p_error where it contains an error message. Upon getting the data from DB, I need to check this field to see what type of an error has been returned, so I can throw an appropriate exceptions. So, I still need to store my error types/error messages somewhere.....In other words, how do I should the exact message to the user (at certain times I need to) w/o checking the p_error field first. WHich brings me back to error object. Anyone?
2) I can this potentially turning into a nightmare where the number of exceptions equals the number of error message types.
Am I missing something here?
Much thanks to everyone!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
您应该查看企业库中的异常处理块。 关于包装异常并在层之间传递它们有很多好的技巧和代码软件。
You should check out the exception handling block in Enterprise Library. Lots of good tips and codeware surrounding wrapping exceptions and passing them between layers.
您的业务层在哪里？为什么它不检查授权和完整性？ DAL 的级别太低，无法检查这些规则 - 如果您在那里遇到问题，那么差不多就该抛出异常了。 您的业务层或控制器可以捕获该异常，并显示合理的消息 - 但这不是您应该经常做的事情。
Where's your business layer, and why isn't it checking Authorization and integrity? The DAL is too low level to be checking those rules - if you hit a problem there, it's pretty much time to throw an exception. Your business layer or controllers can catch that exception, and display a reasonable message - but it's not something you should regularly be doing.
创建您自己的异常层。
DAL异常管理器
重复异常
数据库异常
BLLExceptionManager
未授权异常
InvalidDateException
在您的表示层中，添加此引用并创建一个公共异常处理程序。
这样你就知道如何处理异常消息了。
Create your own exception layer.
DALExceptionManager
DuplicateException
DatabaseException
BLLExceptionManager
NotAuthorizedException
InvalidDateException
In your Presentation Layer, Add this references and create a common exception handler.
In this way you know how to deal with the exception messages.
我不确定我是否理解这一点。 您不必在每一层中传递错误对象。 例如，在您的一个示例中，
错误通知用户数据库中已存在类似的内容（例如，名称不唯一），框架可能会抛出 sql 异常，您只需要在业务层或 UI 层捕获特定的异常即可。其他人建议的企业库的异常处理块将允许您在 web.config 文件中定义一些基于策略的异常处理。 如果您想开发一些企业应用程序，这可能是个好地方。 但对于简单的应用程序，您可能不需要走那么远。
I am not sure I understand this. You don't have to pass the error object in every layer. For example, in one of your example,
errors that inform the user that something like this already exists in the database (say name not unique - for example), a sql exception could be thrown by the framework, and you just need to catch the specific exception in your business layer, or UI layer.Exception handling block by the Enterprise library suggested by other people will allow you define some policy-based exception handling in your web.config file. It could be good place if you want to develop some enterprise application. But for simple application, you may need not go that far.
上层发生的事情不取决于您的数据访问层。 它甚至不应该知道上层要做什么。 如果您遇到重复键错误，那么它应该抛出类似“DuplicateKeyException”的内容。 如果您遇到授权错误（我猜您的意思是“异常”），则不要对其执行任何操作 - 让它冒泡回 UI 层，该层可以显示适当的错误页面。
请记住，错误状态值和此类事物是我们发明异常的原因。
What happens in the upper layers isn't up to your Data Access Layer. It shouldn't even be aware of what the upper layers are going to do. If you've got a duplicate key error, then it should throw something like a "DuplicateKeyException". If you should hit an authorization error (I presume you mean "exception"), then don't do anything with it - let it bubble back up to the UI layer, which can display an appropriate error page.
Remember that error status values and such things are the reason we invented exceptions.
正如许多人指出的那样，企业库异常处理块是炸弹。 使用策略，您可以执行一些操作，例如记录异常、将其包装在不同的异常中、抛出新的异常而不是原始异常。 此外，如果您希望根据身份验证错误或重复记录错误等执行特定操作，您始终可以创建特定的派生异常类并捕获这些异常类型，这将消除从上到下传递任何对象的需要。 异常应该总是向上冒泡，而不是向下冒泡。
Enterprise library exception handling block is the bomb as many have pointed out. Using policies you can do things like logging the exception, wrapping it in a different exception, throwing a new exception instead of the original one. Also, if you are looking to perform specific actions based on authentication errors or duplicate record errors etc, you could always create specific derived exception classes and catch those exception types which would precludes the need of passing any objects from the top down. Exceptions should always bubble up not down.