在做了一些研究之后，AppDomains 似乎并不是真正的构建托管服务器的工具。据我了解，如果创建的 AppDomain 中存在未处理的异常（如果从创建的 AppDomain 中的线程抛出异常），托管服务器仍然会崩溃。因此，在这种情况下，如果托管服务器托管的服务泄漏异常，这也会关闭默认的 AppDomain。
所以我想从服务器架构的角度来看，没有什么比创建子进程并监控它们更好的了。
这是正确的还是我错过了 AppDomains 的某些内容？
谢谢， 克里斯托夫
【问题讨论】：
如果您可以控制在其他 AppDomain 中创建的线程，您还可以通过在线程主方法中使用 catch-all 块来处理异常。
除此之外，只要你使用默认主机，我相信你的假设是正确的。但是，如果您自己托管运行时，您也可以处理未处理的异常。
嗯，这是可能的。你必须 创建您自己的 CLR 主机。那开始 使用 ICorBindToRuntimeEx()。你得到 完全控制 AppDomains 抛出异常。它正在 由 MSFT 软件（如 ASP.NET 和 SQL Server 2005。当你写一个 服务，您正在与 默认 CLR 主机实现及其 任何时候终止进程 引发未处理的异常， 不管 AppDomain 造成了什么 例外。
问题是，像 ASP.NET 和 SQL 这样的主机 服务器有一个非常明确的代码 执行路径。在网络服务器中， 托管代码因页面而运行 要求。在 dbase 服务器中，它运行 因为一个查询。当某事 坏事发生了，他们有幸 简单地中止所有 请求开始（杀死 AppDomain) 并返回“对不起， 做不到”状态回到 客户。你可能见过， 使旧版论坛服务器崩溃 网站很简单，但没有 阻止它服务其他请求。 实际上并不是 100% 确定这一点。
您的服务实现是 可能没有那么干净。我不能 告诉，你什么都没说 它。一般，有问题 中止线程。你一直 当有一个线程时必须中止一个线程 未处理的异常。一项服务 通常有一个线程，由 OnStart() 方法。中止它 杀死服务器直到有人停止 然后重新开始。
你绝对可以做得更多 比这更有弹性，你可以开始一个 启动子进程的“主”线程 响应外部事件的线程 这使您的服务发挥作用。 终止子线程 因为一个未处理的异常是 你可能会恢复的东西 从。但是，如果你下一个 步骤，为什么没有子线程 捕获异常并将其传递回 主线程，因此它可以制作一个 关于做什么的明智决定 下一个。
默认 CLR 的冷酷事实 主持人是：如果你不愿意 处理失败，它不会 为你做这项工作。而且不应该， .NET 1.x 对线程的行为 死于异常是一个主要的 在 .NET 中得到纠正的错误 2.0。
你知道该怎么做：处理失败。 或者写你自己的主机。或者接受 事情可能超出你的控制 并记录一个好的错误消息，这样你 可以告诉您的客户该做什么。 我强烈推荐后者。
【讨论】：