我正在为一个朋友检查一些代码，并说他在try-finally块中使用了return语句。即使try块的其余部分没有触发，Finally部分中的代码仍然会触发吗?
例子:
public bool someMethod()
{
try
{
return true;
throw new Exception("test"); // doesn't seem to get executed
}
finally
{
//code in question
}
}
通常情况下,是的。finally部分保证执行发生的任何事情，包括异常或返回语句。该规则的异常是线程上发生的异步异常(OutOfMemoryException, StackOverflowException)。
要了解在这种情况下异步异常和可靠代码的更多信息，请阅读约束执行区域。
这里有一个小测试:
class Class1
{
[STAThread]
static void Main(string[] args)
{
Console.WriteLine("before");
Console.WriteLine(test());
Console.WriteLine("after");
}
static string test()
{
try
{
return "return";
}
finally
{
Console.WriteLine("finally");
}
}
}
结果是:
before
finally
return
after
通常是的，最终会运行。
对于以下三种情况，finally将始终运行:
No exceptions occur Synchronous exceptions (exceptions that occur in normal program flow). This includes CLS compliant exceptions that derive from System.Exception and non-CLS compliant exceptions, which do not derive from System.Exception. Non-CLS compliant exceptions are automatically wrapped by the RuntimeWrappedException. C# cannot throw non-CLS complaint exceptions, but languages such as C++ can. C# could be calling into code written in a language that can throw non-CLS compliant exceptions. Asynchronous ThreadAbortException As of .NET 2.0, a ThreadAbortException will no longer prevent a finally from running. ThreadAbortException is now hoisted to before or after the finally. The finally will always run and will not be interrupted by a thread abort, so long as the try was actually entered before the thread abort occurred.
下面的场景，最后将不会运行:
Asynchronous StackOverflowException. As of .NET 2.0 a stack overflow will cause the process to terminate. The finally will not be run, unless a further constraint is applied to make the finally a CER (Constrained Execution Region). CERs should not be used in general user code. They should only be used where it is critical that clean-up code always run -- after all the process is shutting down on stack overflow anyway and all managed objects will therefore be cleaned-up by default. Thus, the only place a CER should be relevant is for resources that are allocated outside of the process, e.g., unmanaged handles.
通常，非托管代码在被用户代码使用之前由某个托管类包装。托管包装器类通常会使用SafeHandle来包装非托管句柄。SafeHandle实现了一个关键的终结器和一个在CER中运行的Release方法，以保证清理代码的执行。出于这个原因，您不应该看到cer遍布整个用户代码。
因此，finally不运行在StackOverflowException上的事实应该对用户代码没有影响，因为进程无论如何都会终止。如果你有一些边缘情况，你确实需要清理一些非托管资源，在SafeHandle或CriticalFinalizerObject之外，然后使用CER如下所示;但请注意，这是一种糟糕的做法——非托管概念应该通过设计抽象为托管类和适当的安全句柄。
例如,
// No code can appear after this line, before the try
RuntimeHelpers.PrepareConstrainedRegions();
try
{
// This is *NOT* a CER
}
finally
{
// This is a CER; guaranteed to run, if the try was entered,
// even if a StackOverflowException occurs.
}
最后不会运行的情况下，如果你正在退出应用程序使用 system . exit (0);就像在
try
{
System.out.println("try");
System.exit(0);
}
finally
{
System.out.println("finally");
}
结果将是: 试一试
我意识到我迟到了，但在确实抛出异常的场景(与OP的示例不同)中，MSDN声明(https://msdn.microsoft.com/en-us/library/zwc8s4fz.aspx):“如果没有捕获异常，finally块的执行取决于操作系统是否选择触发异常unwind操作。”
The finally block is only guaranteed to execute if some other function (such as Main) further up the call stack catches the exception. This detail is usually not a problem because all run time environments (CLR and OS) C# programs run on free most resources a process owns when it exits (file handles etc.). In some cases it may be crucial though: A database operation half underway which you want to commit resp. unwind; or some remote connection which may not be closed automatically by the OS and then blocks a server.
99%的情况下，finally块内的代码将会运行，但是，想想这个场景:你有一个线程，它有一个try->finally块(没有catch)，你在该线程中得到一个未处理的异常。在这种情况下，线程将退出，它的finally块将不会执行(在这种情况下，应用程序可以继续运行)。
这种情况非常罕见，但这只是为了表明答案并不总是“是”，大多数情况下是“是”，有时在极少数情况下是“否”。
finally块的主要目的是执行写入其中的内容。它不应该取决于try或catch中发生的任何事情。但是使用System.Environment.Exit(1)，应用程序将退出而不移动到下一行代码。
有一个非常重要的例外，我在其他任何答案中都没有看到过，而且(在用c#编程了18年之后)我不敢相信我不知道。
如果你在catch块中抛出或触发任何类型的异常(不仅仅是奇怪的stackoverflowexception和类似的东西)，并且你没有在另一个try/catch块中包含整个try/catch/finally块，你的finally块将不会执行。这很容易证明-如果我没有自己看到它，考虑到我经常读到它只是非常奇怪的，微小的角落情况，可以导致finally块不执行，我不会相信它。
static void Main(string[] args)
{
Console.WriteLine("Beginning demo of how finally clause doesn't get executed");
try
{
Console.WriteLine("Inside try but before exception.");
throw new Exception("Exception #1");
}
catch (Exception ex)
{
Console.WriteLine($"Inside catch for the exception '{ex.Message}' (before throwing another exception).");
throw;
}
finally
{
Console.WriteLine("This never gets executed, and that seems very, very wrong.");
}
Console.WriteLine("This never gets executed, but I wasn't expecting it to.");
Console.ReadLine();
}
我相信这是有原因的，但奇怪的是，它并没有广为人知。(例如，这里提到了，但在这个特定的问题中没有提到。)
