AppDomains 与强大的服务器

经过一些研究后，AppDomains 似乎并不是真正构建托管服务器的工具。根据我的理解，如果创建的AppDomain中存在未处理的异常（如果从创建的AppDomain中的线程抛出异常），托管服务器仍然会崩溃。因此，在这种情况下，如果托管服务器托管的服务泄漏了异常，这也会导致默认的 AppDomain 崩溃。

所以我想从服务器架构的角度来看，没有什么比创建子进程并监视它们更好的了。

这是正确的还是我错过了 AppDomains 的某些内容？

谢谢， 克里斯托夫

如果您可以控制在其他 AppDomain 中创建的线程，则还可以通过在线程 main 方法中使用 catch-all 块来处理异常。

除此之外，只要您使用默认主机，我相信您的假设是正确的。但是，如果您自己托管运行时，则还可以处理未处理的异常。

From a 关于该主题的论坛帖子 http://social.msdn.microsoft.com/Forums/en-US/clr/thread/a508c1a0-3c65-45a9-8c89-d809faf1ca0b:

嗯，这是可能的。你必须 创建您自己的 CLR 主机。那开始 使用 ICorBindToRuntimeEx()。你得到 完全控制 AppDomains 抛出异常。而它正在 由 MSFT 软件（例如 ASP.NET 和）使用 SQL Server 2005。当您编写 服务，您正在与 默认 CLR 主机实现及其 当任何情况下终止进程 引发未处理的异常， 不管 AppDomain 造成了什么 例外。

问题是，像 ASP.NET 和 SQL 这样的主机 服务器有一个非常明确的代码 执行路径。在网络服务器中， 托管代码因页面而运行 要求。在数据库服务器中，它运行 因为一个查询。当某事 坏事发生了，他们有幸 只是中止一切 请求开始（杀死 AppDomain）并返回“抱歉， 无法做到这一点”状态返回到 客户。你可能已经看过了， 旧版论坛服务器崩溃 网站非常琐碎，但没有 阻止它服务其他请求。 实际上并不能100%确定这一点。

您的服务实现是 可能不太干净。我不能 告诉你，你什么也没说 它。一般，有问题 中止线程。你一直 当有一个线程时必须中止一个线程 未处理的异常。一项服务 通常有一个线程，由 OnStart() 方法。中止它 杀死服务器直到有人停止 并再次开始。

你绝对可以做得更多 比这更有弹性，你可以开始 启动子进程的“主”线程 响应外部事件的线程 这使您的服务发挥其作用。 终止子线程 因为未处理的异常是 你可能恢复的东西 从。但如果你接下来这么做 步骤，为什么没有子线程 捕获异常并将其传回 主线程，这样它就可以制作一个 关于做什么的明智决定 下一个。

默认 CLR 的冷酷事实 主持人是：如果你不愿意 面对失败，它不会 为你做这份工作。而且不应该， .NET 1.x 的线程行为 异常死亡是一个重大事件 .NET 中已更正的错误 2.0。

你知道该怎么做：处理失败。 或者写你自己的主机。或者接受这一点 事情可能超出你的控制范围 并记录一个好的错误消息，以便您 可以告诉您的客户该怎么做。 我强烈推荐后者。