我的异常处理策略是：
要通过挂钩来捕获所有未处理的异常Application.ThreadException event，然后决定：
然后我总是将在外部运行的每一段代码都包含在try/catch：
然后我附在“尝试/捕获”中
ApplicationException("custom message", innerException)的来跟踪真正发生的事情此外，我尽我所能正确地对异常进行排序。有以下例外情况：
需要立即显示给用户
当它们发生时需要一些额外的处理来将它们放在一起以避免级联问题（即：在填充期间将 .EndUpdate 放在该finally部分中TreeView）
用户不在乎，但重要的是要知道发生了什么。所以我总是记录它们：
在事件日志中
或在磁盘上的 .log 文件中
设计一些静态方法来处理应用程序顶级错误处理程序中的异常是一种很好的做法。
我也强迫自己尝试：
所以最后：
坏的：
// DON'T DO THIS; ITS BAD
try
{
...
}
catch
{
// only air...
}
无用：
// DON'T DO THIS; IT'S USELESS
try
{
...
}
catch(Exception ex)
{
throw ex;
}
最后尝试没有捕获是完全有效的：
try
{
listView1.BeginUpdate();
// If an exception occurs in the following code, then the finally will be executed
// and the exception will be thrown
...
}
finally
{
// I WANT THIS CODE TO RUN EVENTUALLY REGARDLESS AN EXCEPTION OCCURRED OR NOT
listView1.EndUpdate();
}
我在顶层做什么：
// i.e When the user clicks on a button
try
{
...
}
catch(Exception ex)
{
ex.Log(); // Log exception
-- OR --
ex.Log().Display(); // Log exception, then show it to the user with apologies...
}
我在一些被调用的函数中做了什么：
// Calculation module
try
{
...
}
catch(Exception ex)
{
// Add useful information to the exception
throw new ApplicationException("Something wrong happened in the calculation module:", ex);
}
// IO module
try
{
...
}
catch(Exception ex)
{
throw new ApplicationException(string.Format("I cannot write the file {0} to {1}", fileName, directoryName), ex);
}
异常处理（自定义异常）有很多关系，但我试图记住的那些规则对于我所做的简单应用程序来说已经足够了。
这是一个扩展方法的示例，可以以一种舒适的方式处理捕获的异常。它们以可以链接在一起的方式实现，并且很容易添加自己的捕获异常处理。
// Usage:
try
{
// boom
}
catch(Exception ex)
{
// Only log exception
ex.Log();
-- OR --
// Only display exception
ex.Display();
-- OR --
// Log, then display exception
ex.Log().Display();
-- OR --
// Add some user-friendly message to an exception
new ApplicationException("Unable to calculate !", ex).Log().Display();
}
// Extension methods
internal static Exception Log(this Exception ex)
{
File.AppendAllText("CaughtExceptions" + DateTime.Now.ToString("yyyy-MM-dd") + ".log", DateTime.Now.ToString("HH:mm:ss") + ": " + ex.Message + "\n" + ex.ToString() + "\n");
return ex;
}
internal static Exception Display(this Exception ex, string msg = null, MessageBoxImage img = MessageBoxImage.Error)
{
MessageBox.Show(msg ?? ex.Message, "", MessageBoxButton.OK, img);
return ex;
}
最佳实践是异常处理永远不应该隐藏问题。这意味着try-catch块应该非常罕见。
在 3 种情况下使用 atry-catch是有意义的。
始终尽可能低调地处理已知异常。但是，如果您预计会出现异常，通常最好先对其进行测试。例如，解析、格式化和算术异常几乎总是首先通过逻辑检查来更好地处理，而不是特定的try-catch.
如果您需要对异常执行某些操作（例如记录或回滚事务），则重新抛出异常。
始终尽可能高地处理未知异常 -唯一应该使用异常而不重新抛出异常的代码应该是 UI 或公共 API。
假设您正在连接到远程 API，在这里您知道会出现某些错误（并且在这种情况下会发生错误），所以这是案例 1：
try
{
remoteApi.Connect()
}
catch(ApiConnectionSecurityException ex)
{
// User's security details have expired
return false;
}
return true;
请注意，没有其他异常被捕获，因为它们不是预期的。
现在假设您正在尝试将某些内容保存到数据库中。如果失败，我们必须回滚它，所以我们有案例 2：
try
{
DBConnection.Save();
}
catch
{
// Roll back the DB changes so they aren't corrupted on ANY exception
DBConnection.Rollback();
// Re-throw the exception, it's critical that the user knows that it failed to save
throw;
}
请注意，我们重新抛出异常 - 更高的代码仍然需要知道某些事情已经失败。
最后我们有了 UI——在这里我们不希望有完全未处理的异常，但我们也不想隐藏它们。这里我们有一个案例 3 的例子：
try
{
// Do something
}
catch(Exception ex)
{
// Log exception for developers
WriteException2LogFile(ex);
// Display message to users
DisplayWarningBox("An error has occurred, please contact support!");
}
但是，大多数 API 或 UI 框架都有处理案例 3 的通用方法。例如，ASP.Net 有一个黄色错误屏幕，用于转储异常详细信息，但可以在生产环境中用更通用的消息替换。遵循这些是最佳实践，因为它可以为您节省大量代码，而且还因为错误记录和显示应该是配置决策而不是硬编码。
这一切都意味着案例 1（已知异常）和案例 3（一次性 UI 处理）都有更好的模式（避免预期错误或将错误处理交给 UI）。
甚至情况 2 也可以用更好的模式代替，例如事务范围（using回滚在块期间未提交的任何事务的块）使开发人员更难将最佳实践模式弄错。
例如，假设您有一个大型 ASP.Net 应用程序。错误记录可以通过ELMAH 进行，错误显示可以是本地的 YSoD 信息，也可以是生产中很好的本地化消息。数据库连接都可以通过事务范围和using块。你不需要一个try-catch块。
TL;DR：最佳实践实际上是根本不使用try-catch块。
异常是阻塞错误。
首先，最佳实践应该是不要为任何类型的错误抛出异常，除非它是一个阻塞错误。
如果错误是阻塞的，则抛出异常。一旦异常已经抛出，就不需要隐藏它，因为它是异常的；让用户知道它（你应该在 UI 中将整个异常重新格式化为对用户有用的东西）。
作为软件开发人员，您的工作是努力防止某些参数或运行时情况可能以异常结束的异常情况。也就是说，不能忽略异常，但必须避免这些异常。
例如，如果您知道某些整数输入可能带有无效格式，请使用int.TryParse而不是int.Parse. 在很多情况下，您可以这样做，而不仅仅是说“如果失败，只需抛出异常”。
抛出异常是昂贵的。
毕竟，如果抛出异常，而不是在抛出异常后将异常写入日志，最佳实践之一是在第一次机会异常处理程序中捕获它。例如：
我的立场是，本地 try/catch 更适合处理特殊情况，您可能会将异常转换为另一个异常，或者当您想在非常、非常、非常、非常、非常特殊的情况下“静音”它（库错误抛出一个不相关的异常，您需要静音才能解决整个错误）。
对于其余情况：
@thewhiteambit 说：
异常不是致命错误，它们是异常！有时它们甚至不是错误，但将它们视为致命错误是对异常是什么的完全错误的理解。
首先，异常怎么不能是错误？
null=>异常我们可能会列出 1k 种抛出异常的情况，毕竟任何可能的情况都是错误的。
异常就是错误，因为归根结底，它是一个收集诊断信息的对象——它有一条消息，并且在出现问题时发生。
当没有异常情况时，没有人会抛出异常。异常应该是阻塞错误，因为一旦它们被抛出，如果你不尝试使用 try/catch 和异常来实现控制流，它们意味着你的应用程序/服务将停止进入异常情况的操作。
另外，我建议大家查看Martin Fowler（由 Jim Shore 撰写）发布的快速失败范例。这就是我一直了解如何处理异常的方式，甚至在我前一段时间阅读本文档之前。
[...] 将它们视为致命错误是对异常是什么的完全错误的理解。
通常异常会切断一些操作流程，并对其进行处理以将其转换为人类可以理解的错误。因此，似乎异常实际上是处理错误情况并对其进行处理以避免应用程序/服务完全崩溃并通知用户/消费者出现问题的更好范例。
例如，在缺少数据库连接的情况下，程序可以异常地继续写入本地文件，并在数据库再次可用时将更改发送到数据库。可以尝试使用异常上的语言本地解释再次解析您无效的字符串到数字转换，就像您尝试将默认英语语言解析为 Parse("1,5") 失败并且您再次尝试使用德语解释时，这完全是很好，因为我们使用逗号而不是点作为分隔符。您会看到这些异常甚至不能被阻塞，它们只需要一些异常处理。
如果您的应用程序可能在不将数据持久化到数据库的情况下脱机工作，则不应使用exceptions，因为使用实现控制流try/catch被视为反模式。离线工作是一个可能的用例，因此您实施控制流来检查数据库是否可访问，您不要等到它无法访问。
解析的事情也是一个预期的情况（不是例外情况）。如果您期望这一点，则不要使用异常来进行控制流！. 您从用户那里获得一些元数据以了解他/她的文化，并为此使用格式化程序！.NET 也支持这种环境和其他环境，但如果您希望应用程序/服务具有特定于文化的用法，则必须避免使用数字格式，这是一个例外。
未处理的异常通常会变成错误，但异常本身不是 codeproject.com/Articles/15921/Not-All-Exceptions-Are-Errors
本文只是作者的观点或观点。
由于 Wikipedia 也可能只是文章作者的意见，我不会说这是教条，但请检查Coding by exception文章在某段某处所说的内容：
[...] 使用这些异常来处理出现的特定错误以继续程序被称为异常编码。这种反模式会迅速降低软件的性能和可维护性。
它还在某处说：
异常使用不正确
通常，异常编码可能会导致软件中出现异常使用不正确的进一步问题。除了对一个独特的问题使用异常处理之外，不正确的异常使用会通过执行代码甚至在引发异常之后更进一步。这种糟糕的编程方法类似于许多软件语言中的 goto 方法，但仅在检测到软件中的问题后才会发生。
老实说，我认为如果不认真对待用例，就无法开发软件。如果你知道...
...您不会为此使用异常。您将使用常规控制流来支持这些用例。
如果没有涵盖某些意外用例，您的代码将很快失败，因为它会抛出异常。对，因为异常就是特例。
另一方面，最后，有时您会涵盖抛出预期异常的异常情况，但您不会抛出它们来实现控制流。您这样做是因为您想通知上层您不支持某些用例，或者您的代码无法使用某些给定的参数或环境数据/属性。
您唯一应该让用户担心代码中发生的事情是他们可以或需要做些什么来避免该问题。如果他们可以更改表单上的数据、按下按钮或更改应用程序设置以避免问题，请让他们知道。但是用户无法避免的警告或错误只会让他们对你的产品失去信心。
异常和日志是给你的，开发者，而不是你的最终用户。在捕获每个异常时了解正确的做法远比仅仅应用一些黄金法则或依赖应用程序范围的安全网要好得多。
盲目的编码是唯一一种错误的编码。你觉得在这些情况下可以做一些更好的事情，这表明你对良好的编码进行了投资，但避免试图在这些情况下标记一些通用规则，并首先了解要抛出某些东西的原因以及什么你可以从中恢复过来。
我知道这是一个老问题，但是这里没有人提到 MSDN 文章，并且实际上是该文档为我清理了它，MSDN 对此有一个非常好的文档，当以下条件为真时，您应该捕获异常：
您对可能引发异常的原因有了很好的理解，并且可以实现特定的恢复，例如在捕获 FileNotFoundException 对象时提示用户输入新文件名。
您可以创建并抛出一个新的、更具体的异常。
int GetInt(int[] array, int index)
{
try
{
return array[index];
}
catch(System.IndexOutOfRangeException e)
{
throw new System.ArgumentOutOfRangeException(
"Parameter index is out of range.");
}
}
- 您希望在将异常传递给其他处理之前对其进行部分处理。在以下示例中，catch 块用于在重新引发异常之前将条目添加到错误日志中。
try
{
// Try to access a resource.
}
catch (System.UnauthorizedAccessException e)
{
// Call a custom error logging procedure.
LogError(e);
// Re-throw the error.
throw;
}
第二种方法是一个很好的方法。
如果您不想显示错误并通过显示与他们无关的运行时异常（即错误）来混淆应用程序用户，那么只需记录错误，技术团队就可以查找问题并解决它。
try
{
//do some work
}
catch(Exception exception)
{
WriteException2LogFile(exception);//it will write the or log the error in a text file
}
我建议您为整个应用程序采用第二种方法。
更好的方法是第二种方法（您指定异常类型的方法）。这样做的好处是您知道这种类型的异常可能发生在您的代码中。您正在处理这种类型的异常，您可以恢复。如果出现任何其他异常，则意味着出现问题，这将帮助您在代码中找到错误。应用程序最终会崩溃，但您会发现有一些您遗漏的东西（错误）需要修复。
有例外，我尝试以下方法：
首先，我捕获特殊类型的异常，例如除零、IO 操作等，并据此编写代码。例如，除以零，这取决于我可以提醒用户的值的来源（例如一个简单的计算器，在中间计算（不是参数）中到达除以零）或静默处理该异常，记录它并继续处理。
然后我尝试捕获剩余的异常并记录它们。如果可能，允许执行代码，否则会提醒用户发生错误并要求他们邮寄错误报告。
在代码中，是这样的：
try{
//Some code here
}
catch(DivideByZeroException dz){
AlerUserDivideByZerohappened();
}
catch(Exception e){
treatGeneralException(e);
}
finally{
//if a IO operation here i close the hanging handlers for example
}
最佳实践是在发生错误时抛出异常。因为发生了错误，它不应该被隐藏。
但在现实生活中，当你想隐藏它时，你可能会遇到几种情况
留下空白的 catch 块是最糟糕的事情。如果出现错误，最好的处理方法是：
有时您需要处理对用户无意义的异常。
我的方法是：
它绝对不一定是最佳实践。;-)
对我来说，处理异常可以看作是业务规则。显然，第一种方法是不可接受的。第二个更好，如果上下文这样说，它可能是 100% 正确的方式。现在，例如，您正在开发 Outlook 插件。如果您的插件抛出未处理的异常，Outlook 用户现在可能知道它，因为 Outlook 不会因为一个插件失败而自行销毁。而且你很难弄清楚出了什么问题。因此，在这种情况下，第二种方法对我来说是正确的。除了记录异常，您可能会决定向用户显示错误消息——我认为这是一个业务规则。
没有任何参数的catch只是吃异常并且没有用。如果发生致命错误怎么办？如果你不带参数地使用 catch ，就无法知道发生了什么。
catch 语句应该捕获更具体的异常，例如FileNotFoundException，然后在最后你应该捕获Exception它会捕获任何其他异常并记录它们。
您应该考虑这些例外设计指南
https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/exceptions
我可以告诉你一些事情：
Snippet #1 是不可接受的，因为它忽略了异常。（它像什么都没发生一样吞下它）。
所以不要添加什么都不做或只是重新抛出的 catch 块。
Catch 块应该增加一些价值。例如向最终用户输出消息或记录错误。
不要对正常流程程序逻辑使用异常。例如：
例如输入验证。<- 这是无效的例外情况，您应该编写方法IsValid(myInput);来检查输入项是否有效。
设计代码以避免异常。例如：
int Parse(string input);
如果我们将无法解析的值传递给 int，则此方法将抛出异常，而不是我们可能会编写如下内容：
bool TryParse(string input,out int result);<- 此方法将返回布尔值，指示解析是否成功。
也许这有点超出了这个问题的范围，但我希望这能帮助你在遇到try {} catch(){}例外情况时做出正确的决定。