全局异常处理 VS Try catch 无处不在答案

【问题标题】：Global exception handling VS Try catch everywhere全局异常处理 VS Try catch 无处不在
【发布时间】：2020-02-10 03:32:54
【问题描述】：

最近我在我的代码中使用了全局异常处理，我开始知道这样可以处理所有异常。以前我在每个控制器上都使用 try-catch，现在我已经从控制器中删除了所有 try-catch，因为全局异常，因为它可以处理所有类型的异常。

所以我怀疑，删除我以前在控制器中用于全局异常处理的所有异常处理是否是一种好习惯，或者应该同时使用全局以及控制器上的 try-catch。

如果需要try-catch，是否有必要在控制器级别处理所有异常。

我当前的工作堆栈是 - .Net Core。

【问题讨论】：

欢迎来到 StackOverflow。你可以开始阅读here。
一般规则 - 尽可能少使用全局异常处理。
实际上，它还取决于您正在执行的工作类型，例如，如果您正在创建 API，并且您希望在每个函数上返回自定义错误消息，而不是像 “出现问题”这样的通用消息 然后不要使用全局异常处理程序。但是是的，全局异常处理程序在我们的应用程序范围太大的情况下有时很重要，并且在每个异常上我们只需要向用户显示一个简单的错误消息。它将节省您的开发时间并减少代码。
@NaumanKhan，我们是否应该总是在控制器级别捕获异常，如果我在业务逻辑层捕获异常而不是在控制器中抛出异常呢。
@BippanSingh 是的，如果你有业务逻辑层而不是在控制器中做所有事情，你应该总是在业务逻辑层捕获异常而不是把它扔给控制器（使用自定义消息）。

【解决方案1】：

这个问题太笼统了，无法给出完整的答案，但是，让我对这个问题发表我的看法。

try-catch-finally 块不用于处理未处理的异常。那些你从来没想过的案子自然不会被处理，你不应该保持沉默，但你应该让他们表达自己，让你去思考。处理的异常虽然是程序员不掌握但他/她已经考虑过的情况。例如用户输入的是字符串而不是数字。

如果您认为是这种情况但在您的控制范围内，请始终与ifs 联系。例如，如果某些东西可以为空。 Try-catch 真的很昂贵，并且不应该在其中处理任何逻辑。

另一方面，使用全局异常处理程序是完全相反的。并不是要包装所有的思想案例并向用户显示单一的响应。你应该记录未知的异常，然后回来思考它们发生的原因，同时对用户说你很抱歉。 :)

【讨论】：