在哪里放try catch
考虑这种情况：我有3层应用程序，当用户单击按钮时，按钮事件处理程序调用biz层中的方法，该方法对我的按钮事件处理程序提供的数据执行任何操作，然后将该数据传递给发送的数据Access层他们到后端数据库。 问题是在哪里放试试？ 在数据层，在商业层，在表示层或可能把它放在所有这些？ 在这种情况下，表示exception处理的最佳策略是什么？
我们跟着
如果您不知道如何处理exception，请不要捕获exception。
我们从不处理任何我们无法处理或违约的例外情况。 它被冒泡了，我们在应用程序级别处理它。
假设您可以为业务对象默认值，则可以在业务层中处理它。
绝对放置一个最接近用户的try catch – 因为在那个位置你可以将它翻译成对你的用户有意义的东西。
如果您打算对它们执行某些操作，则只需要更深入的尝试捕获 – 例如，处理exception，或者记录并重新抛出exception。
exception处理的口头禅是：“早点扔，迟到”。 您希望在最后可能的时刻捕获exception，但是您希望立即抛出exception（在确定错误后再执行更多处理，然后抛出exception）。 如果你不能“处理”exception，那么就不要抓住它。
在大多数情况下，尝试…最后块在您的代码中应该比Try … Catch更常见。
可能最好在所有图层中使用try catch，但只能在UI层中静默捕获exception。 在商业和数据访问层中，您应该在重新投掷之前捕获exception并记录信息
try { //do something } catch(Exception ex) { LogFile.WriteLine(ex.ToString()); throw; } 注意：不要写：
throw ex;
因为这将清除exception中所有有用的堆栈信息。
把try-catch放在你确定不会吞下exception的地方。 如果可以确保一致性，则可以在各个层中使用多个try-catch块。
例如，您可以在数据访问层中放置try-catch以确保正确清理连接。 但是，由于你不能做更多的事情，你应该重新抛出exception。
移动到业务层，您可以将try-catch放在要以primefaces方式进行的多个数据库操作中。 在这种情况下，您可能应该回滚所有内容或将事物置于一致状态，在某处记录exception。 吞咽或再饲养应根据具体情况决定。
您的表示层应始终捕获所有exception，无论是某些Web应用程序，在浏览器中运行的脚本还是某些富客户端应用程序。 您可能无法完全理解exception，但至少可以确保您的应用程序不会在用户面前死亡。
当然，这只是一条建议。 因人而异。 🙂
这取决于你真正想要做些什么。 通常我会在业务层中捕获它，然后记录它并可能调用一些ui函数来向用户显示消息。
我考虑如何处理业务规则中的错误。 它应该与数据层或ui层分开。
一般的答案是：随时可以处理被抛出的东西。 也就是说，决定很简单。 例如，捕获创建所需对象时出现的exception。
始终尝试/捕获顶级或控制器级别。
UI仅用于演示。 你不会在那里捕获exception，因为弄清楚如何处理它意味着逻辑。 这属于业务层或控制器层。 在最坏的情况下，您捕获exception并将其映射到适当的，用户友好的错误消息，然后将其发送到演示文稿以供显示。
当我有这样的多层架构（这很多）时，我经常会在多个层上进行try / catch。 例如，持久层中捕获SQLException的try / catch执行持久层需要做的事情（例如，通知管理员）然后抛出一个新的exception，这对于调用持久层的一些代码是有意义的。 一个例子可能是PersistenceException。 下一层并不关心应该通知谁重新启动数据库，但它确实关心它无法保存用户状态，因此它可能会捕获PersistenceException并告诉用户他的新电话号码不是’ t存储在数据库中。
您只想使用try catches来管理未处理的代码。 一个例子是我有一个我正在与之通信的COM对象，我不希望它保持打开并造成内存泄漏。 另一个可接受的替代方法是在允许exception继续之前捕获数据库中事件的错误。
您不希望使用try catch来处理您不确定代码是否有效以及需要备份计划的情况。
因此，当应用程序爆炸时，您会在哪里离开，使用自定义错误页面来指示Web应用程序中出现问题，并且胖客户端将代码解析为工作线程，这样如果它们失败，它们就不会炸毁主线程。 祝好运！