放在哪里尝试捕捉

Question

考虑这种情况： 我有3层应用程序，当此按钮，用户点击该按钮事件处理函数调用BIZ层的方法是做什么用的数据我的按钮事件处理程序的供应，然后通过将数据发送到将数据发送到后端数据库的数据访问层。 问题是在哪里放置try catch？在数据层中，在biz层中，在表示层中或者可以放在所有层中？在这种情况下代表异常处理的最佳策略是什么？

Answer 1

一定会把一个尝试捕捉最接近用户 - 因为在那个位置，你可以把它转化为对用户有意义的事。如果你打算做一些与他们只能需要

更深层次的尝试捕获 - 例如，处理异常，或者是记录并重新抛出异常。

Answer 2

我们遵循

不要捕捉异常，如果你不知道该怎么办。

我们从来没有处理，我们不能处理或默认任何异常。它会冒泡，我们会在应用程序级别处理它。

说一下，如果您可以为业务对象默认值，那么您可以在业务层中处理它。

Answer 3

这只取决于你真正想要做些什么。通常我在业务层捕获它，然后记录它并可能调用一些ui函数向用户显示一条消息。

我考虑如何处理业务规则的错误。它应该与数据层或UI层分开。

Answer 4

一般的答案是：捕捉任何时候，你可以处理什么被抛出。也就是说，这个决定很简单。例如，捕获创建您需要的对象时出现的异常。

Answer 5

也许最好使用尝试捕捉所有层，但只能默默赶在UI层的异常。在biz和数据访问层中，你应该捕获异常并记录信息，然后再重新抛出。

try 
{ 
    //do something 
} 
catch(Exception ex) 
{ 
    LogFile.WriteLine(ex.ToString()); 
    throw; 
} 

注意：不要写：

throw ex; 

，因为这将清除所有从异常有用的堆栈信息。

Answer 6

总是尝试/赶上最高级别或控制器级别。

Answer 7

UI仅供演示。你不会在那里发现异常，因为弄清楚如何处理它意味着逻辑。这属于业务或控制器层。在最坏的情况下，您会捕获异常并将其映射到适当的，用户友好的错误消息，然后将其发送到演示文稿中进行显示。

Answer 8

把try-catch放在你确定不会吞下异常的地方。如果可以确保一致性，则可以在各个图层中使用多个try-catch块。

例如，您可以在数据访问层中放置try-catch，以确保正确清理连接。但是，由于你不能做更多的事情，你应该重新抛出异常。

移至业务层，您可以将try-catch跨多个数据库操作（您希望以原子方式进行）。在这种情况下，可能应该回滚一切或将事物置于一致状态，并在某处记录异常。吞咽或重新投射应根据具体情况决定。

您的表示层应始终捕获所有异常，无论是某个Web应用程序，运行在浏览器中的脚本还是某些富客户机应用程序。您可能无法完全理解异常，但至少可以确保您的应用程序不会在用户面前死亡。

当然，它只是一个建议。因人而异。 :)

Answer 9

当我有一个这样的多层架构（这是一个很多）时，我会经常有一个尝试/抓住不止一层。例如，持久层中捕获SQLException的try/catch，执行持久层需要做的事情（例如，通知管理员），然后抛出一个新的异常，这对调用持久层的代码有意义。一个例子可能是PersistenceException。下一层不关心应该通知谁重新启动数据库，但它确实在意它不能保存用户状态，所以它可能会捕获PersistenceException并告诉用户他的新电话号码不是'存储在数据库中。

Answer 10

异常处理的口头禅是：“早投，迟到”。你想在最后时刻捕捉异常，但是你想立即抛出它们（在确定某些东西是错误的，然后抛出一个异常之后，不要执行更多的处理）。如果你不能“处理”这个异常，那么不要抓住它。

在大多数情况下，Try ... Finally块应该比Try ... Catch更常见。

Answer 11

您只想使用try catch来管理未处理的代码。一个例子是我有一个COM对象与我交流，我不希望它保持开放，并创建一个内存泄漏。另一个可接受的选择是在允许异常继续之前捕获数据库中事件的错误。

你永远不想使用try catch来处理你不确定代码是否工作并想要备份计划的情况。

那么，当应用程序爆炸时，哪里会留下你，使用自定义错误页面来指示您的Web应用程序出现了问题，并且对于胖客户端将代码解析到工作线程中，以便它们不会炸毁主线程他们失败了。祝你好运！