在n层应用程序异常处理？

本文介绍了在n层应用程序异常处理？的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

什么是分层中的应用程序中处理异常的建议的方法和最佳做法？

What is the suggested approach or best practice for handling exceptions in tiered applications?

• 您应该放在哪里的try / catch 块？
• 应该在哪里你实现日志记录？
• 是否有在n层应用程序管理异常的建议模式？

• Where should you place try/catch blocks?
• Where should you implement logging?
• Is there a suggested pattern for managing exceptions in n-tiered applications?

考虑一个简单的例子。假设你有一个用户界面，调用业务层，调用数据层：

Consider a simple example. Suppose you have a UI, that calls a business layer, that calls a data layer:

//UI protected void ButtonClick_GetObject(object sender, EventArgs e) { try { MyObj obj = Business.GetObj(); } catch (Exception ex) { Logger.Log(ex); //should the logging happen here, or at source? MessageBox.Show("An error occurred"); } } //Business public MyObj GetObj() { //is this try/catch block redundant? try { MyObj obj = DAL.GetObj(); } catch (Exception ex) { throw new Exception("A DAL Exception occurred", ex); } } //DAL public MyObj GetObj() { //Or is this try/catch block redundant? try { //connect to database, get object } catch (SqlException ex) { throw new Exception("A SQLException occurred", ex); } }

你会做什么批评的上述异常处理？

What criticisms would you make of the above exception handling?

感谢

推荐答案

我的经验法则通常捕捉异常是在顶层和日志（或其他报告）他们那里，因为这是你对错误最多的信息 - 最重要的是完整的堆栈跟踪

My rule of thumb is generally to catch exceptions at the top level and log (or otherwise report) them there, because this is where you have the most information about the the error - most importantly the full stack trace.

可能有一些原因赶在其他层的例外，但是：

There may be some reasons to catch exceptions in other tiers, however:

的唯一的例外是实际处理的例如。 。连接失败，但一线再尝试吧。

的异常被重新抛出更多的信息的（不是已经可以从看堆栈）。例如。在DAL可能会报告该DB它试图连接，其中的SQLException 也不会告诉你。

的例外被转换成更一般的例外的是用于该层的接口的一部分，并且可以（或可以不）被处理上涨。例如。在DAL可以捕获连接错误，并抛出一个 DatabaseUnavailableException 。该BL可以忽略这对于那些并不重要的操作也可能让它传播完成的那些。如果BL抓的SQLException ，而不是将它暴露在DAL的实现细节。而不是抛出的可能性 DatabaseUnavailableException 是DAL的接口的一部分。

The exception is actually handled. Eg. a connection failed, but the tier re-tries it.

The exception is re-thrown with more information (that isn't already available from looking at the stack). Eg. the DAL might report which DB it was trying to connect to, which SqlException wouldn't tell you.

The exception is translated into a more general exception that is part of the interface for that tier and may (or may not) be handled higher up. Eg. the DAL may catch connection errors and throw a DatabaseUnavailableException. The BL may ignore this for operations that are not critical or it may let it propogate for those that are. If the BL caught SqlException instead it would be exposed to the implementation details of the DAL. Instead the possibility of throwing DatabaseUnavailableException is part of the interface of the DAL.

登录在多个层次相同的错误一般是没有什么用处，但我能想到的一个例外的：当下层不知道问题是否严格或不它可以记录它作为一个警告。如果一个更高层次的决定，它的是的关键就可以登录同样的问题，因为一个错误。

Logging the same error at multiple tiers is generally not useful, but I can think of one exception: when a lower tier doesn't know whether a problem is critical or not it can log it as a warning. If a higher tier decides that it is critical it can then log the same problem as an error.