为什么C#不支持首次通过异常过滤？

注意:这不是Jeff的问题的重复.

那个问题问"是等同的吗？" 我知道没有,我想知道为什么!

我问的原因是我只是清楚它有多重要,结论对我来说似乎很奇怪.

Microsoft企业库的异常处理块建议我们使用此模式:

catch (Exception x)
{
    if (ExceptionPolicy.HandleException(x, ExceptionPolicies.MyPolicy))
        throw;

    // recover from x somehow
}

该策略是在XML文件中定义的,这意味着如果客户遇到问题,我们可以修改策略以帮助跟踪(或者可能还有问题)以便快速解决问题,直到我们正确处理它为止. - 这可能涉及与第三方争论,关于谁的错.

这基本上是对一个简单事实的承认,即在实际应用中,如果没有这样的设施,实际上就无法管理异常类型的数量及其"可恢复性"状态.

与此同时,MS的CLR团队表示这不是一个选择,事实证明这些人知道他们在谈论什么!问题是在catch块运行之前,finally嵌套在块内的任何块try都将被执行.所以这些finally块可能会执行以下任何操作:

无害地修改程序状态(phew,lucky).

在客户的数据中删除重要的东西,因为程序状态被搞砸到了未知程度.

伪装或破坏我们需要诊断问题的重要证据 - 特别是如果我们谈论调用本机代码.

抛出另一个例外,增加了一般的困惑和痛苦.

请注意,using语句和C++/CLI析构函数构建在try/上finally,因此它们也会受到影响.

很明显,过滤异常的catch/ throw模式并不好.实际需要的是一种通过策略过滤异常而不实际捕获它们从而触发finally块执行的方法,除非我们找到一个告诉我们异常可以安全恢复的策略.

CLR团队最近在博客上写了这篇文章:

Catch,Rethrow和Filters - 你为什么要关心？

为什么catch(异常)/空捕获很糟糕

结果是我们必须在VB.NET中编写一个辅助函数,以允许我们从C#访问这个重要的功能.存在问题的一个重要线索就是BCL中有代码可以做到这一点.很多人都写过关于这样做的博客,但他们很少提及关于try/ finallyblocks 的事情,这是杀手.

我想知道的是:

是否有人在C#团队收到有关此主题的公开声明或直接电子邮件？

是否有任何现有的Microsoft Connect建议要求这样做？我听说过他们的谣言,但没有一个可能的关键词出现了什么.

更新:如上所述,我已经搜索过Microsoft Connect而没有找到任何内容.我也(不出所料)谷歌搜索.我只找到人们解释为什么他们需要这个功能,或者指出它在VB.NET中的优势,或者毫无结果地希望它将在未来版本的C#中添加,或者解决它,并且有很多误导性的建议.但没有声明从所有当前版本的C#中省略它的理由.我询问现有Connect问题的原因是(a)我没有创建不必要的副本,(b)我可以告诉感兴趣的人我是否必须创建一个.

更新2:发现了以前来自C#团队的Eric Gunnerson的一篇有趣的老博客文章:

"是的,能够为捕获条件设置一个条件比自己编写测试更方便,但它并不能真正让你做任何新的事情."

这是我的相同假设,直到它被正确解释给我!