Question

考虑这种情况：我有3层应用程序，当用户点击按钮时，按钮事件处理程序调用biz层中的方法，该方法对我的按钮事件处理程序提供的数据执行任何操作，然后将该数据传递给将其发送到后端的数据Access层数据库。问题是在哪里放试试？在数据层，在商业层，在表示层或可能把它放在所有这些？在这种情况下，表示异常处理的最佳策略是什么？

Answer 1

我们关注

如果您不知道如何处理异常，请不要捕获异常。

我们从不处理任何我们无法处理或违约的例外情况。它会冒泡，我们会在应用程序级别处理它。

假设您可以为业务对象默认值，则可以在业务层中处理它。

Answer 2

肯定会将最接近用户的try catch设置为 - 因为在该位置，您可以将其转换为对您的用户有意义的内容。

如果您打算对它们执行某些操作，则只需要更深入的尝试捕获 - 例如，处理异常，或者记录并重新抛出异常。

Answer 3

异常处理的口头禅是：“早点扔，迟到”。你想在最后可能的时刻捕获异常，但是你想立即抛出它们（在确定出错之后再执行一堆处理，然后抛出异常）。如果你无法“处理”异常，那么就不要抓住它。

在大多数情况下，尝试...最后块在代码中应该比Try ... Catch更常见。

Answer 4

可能最好在所有图层中使用try catch，但只能在UI层中静默捕获异常。在商业和数据访问层中，您应该在重新抛出之前捕获异常并记录信息，例如

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

注意：不要写：

throw ex;

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

Answer 5

始终尝试/捕捉顶级或控制器级别。

Answer 6

将try-catch放在您确定不会吞下异常的位置。如果可以确保一致性，可以在各个层中使用多个try-catch块。

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

转移到业务层，您可以将try-catch放在要以原子方式进行的多个数据库操作中。在这种情况下，您可能应该回滚所有内容或将事物置于一致状态，在某处记录异常。吞咽或再饲养应根据具体情况决定。

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

当然，这只是一条建议。因人而异。：）

Answer 7

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

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

Answer 8

一般的答案是：随时可以处理被抛出的东西。也就是说，决定很简单。例如，捕获创建所需对象时出现的异常。

Answer 9

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

Answer 10

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

Answer 11

您只想使用try catches来管理未处理的代码。一个例子是我有一个我正在与之通信的COM对象，我不希望它保持打开并造成内存泄漏。另一个可接受的替代方法是在允许异常继续之前捕获数据库中事件的错误。

您不希望使用try catch来处理您不确定代码是否有效以及需要备份计划的情况。

因此，当应用程序爆炸时，您会离开哪里，使用自定义错误页面来指示您的Web应用程序中出现问题，并且胖客户端将代码解析为工作线程，这样如果它们不会炸毁您的主线程失败。祝你好运！

在哪里放试试

11 个答案: