.net - 为什么 .NET 不记录 StackOverflow 异常的堆栈跟踪？

Question

如果我这样写:

class Program
{
    static void Main(string[] args)
    {
        throw new Exception("lol");
    }
}

并从命令行运行 exe，我的事件日志中有两个条目。一个是应用程序错误，表明存在未处理的异常，另一个包含源为 .NET 运行时的堆栈跟踪。

如果我这样写:

class Program
{
    static void Main(string[] args)
    {
        Recurse4Evr();
    }

    static void Recurse4Evr()
    {
        Recurse4Evr();
    }
}

我在我的事件日志中只得到一个条目，它说应用程序错误并且有一个堆栈溢出异常。堆栈跟踪没有第二个条目，所以它基本上没用。

为什么不记录堆栈跟踪？如果我设置了 DebugDiag 并将其附加到我的进程，然后出现堆栈溢出，DebugDiag 能够记录堆栈跟踪。显然，堆栈跟踪以某种方式可供外界使用。如果运行时因为检测到堆栈溢出而终止进程，那么它也知道堆栈是什么。

在具有许多复杂交互的大型应用程序中，通常不可能重新创建导致堆栈溢出的条件。在这种情况下，堆栈跟踪是找出发生了什么的唯一方法。为什么微软决定记录这些信息并不重要？是否存在不明显的合法设计决策？

Answer 1

堆栈溢出 被认为是不可恢复的情况，因此运行时会终止进程。
总结:
from Damien_The_Unbeliever
来自 StackOverflowException 上的 MSDN 页面s:

In prior versions of the .NET Framework, your application could catch a StackOverflowException object (for example, to recover from unbounded recursion). However, that practice is currently discouraged because significant additional code is required to reliably catch a stack overflow exception and continue program execution.

Starting with the .NET Framework version 2.0, a StackOverflowException object cannot be caught by a try-catch block and the corresponding process is terminated by default. Consequently, users are advised to write their code to detect and prevent a stack overflow. For example, if your application depends on recursion, use a counter or a state condition to terminate the recursive loop. Note that an application that hosts the common language runtime (CLR) can specify that the CLR unload the application domain where the stack overflow exception occurs and let the corresponding process continue. For more information, see ICLRPolicyManager Interface and Hosting the Common Language Runtime.

from JaredPar
从 2.0 开始，只能在以下情况下捕获 StackOverflow 异常。

CLR 正在托管环境中运行，其中主机特别允许处理 StackOverflow 异常

stackoverflow 异常是由用户代码抛出的，而不是由于实际的堆栈溢出情况 ( Reference )