为什么WPF吞下数据绑定异常？

Question

我正在学习WPF，并且很遗憾数据绑定异常不会导致运行时/未处理的异常。

有人能解释数据绑定以这种方式工作的好处吗？我假设有好处，但到目前为止我没有看到任何（免责声明：我刚刚开始使用数据绑定）。

解释做出此决定的理论（或实际）原因的资源链接也可以。

Answer 1

我不确定，但我怀疑是因为没有地方可以处理这个例外。

假设您要绑定某些属性，但有时候某些内容为null。 （例如，{Binding Name.Length}，其中Name是一个可能为null的字符串属性。）在这种情况下，您很高兴这是一个无操作，因为您知道控件将永远不会显示在名称为null（由于触发器说）或因为您知道这将是一个瞬态条件，而绑定源正在加载其数据。

现在假设当尝试在null Name字符串上调用Length时，WPF传播了NullReferenceException。在程序代码中，你会抓住这个异常并吞下它，因为你知道它是良性的。 但是你不能在WPF绑定代码周围放置一个异常处理程序。它是从WPF内部的某个地方调用的。因此异常会一直冒泡到Application.Run，​​这不是一个非常有用的地方。

因此，不是让你在Application.Run中集中你的绑定异常处理程序，我认为WPF的人决定自己吞下异常。只有一个理论......

Answer 2

我认为这是因为制作例外的成本太高了。即使在存在一些无效绑定的情况下，当前实现也可以工作，并且当前形式实际上可以对性能产生非常显着的影响。以此示例为例，创建一个执行绑定的DataGrid，并将1,000条记录加载到其中。测量所有绑定的性能是否正确，并且其中一个绑定错误。差异很大。添加在那个站起来的异常类实例之上，它可能会失控。只是我的意见。

Answer 3

我不知道为什么这是默认行为，但有办法解决。

例如，即使它不会告诉您绑定错误，“输出”窗口也会。您也可以使用绑定验证来捕获它。

修改 我发现this文章有一个非常好的想法，可以创建测试用例来捕获那些恼人的无声绑定错误（我喜欢文章顶部的照片）

Answer 4

这是指向blog post的链接，其中博主写了一个案例，其中认为绑定错误是无声的