Question

注册依赖项属性时，可以使用overload of Register that accepts a validation callback。

如果该验证回调返回值false，则将该值分配给依赖项属性将失败，并且将抛出ArgumentException，抱怨无效的属性值。

现在，虽然ArgumentException在某些情况下是合适的类型，但在某些情况下应该使用一些专门的异常类型。特别是，我声明了enum类型的属性，处理不支持的值的正确方法是抛出InvalidEnumArgumentException。更重要的是，我正在实现一个将enum属性作为CLR属性展示的接口，并且在该属性的doc注释中，需要为无效值抛出InvalidEnumArgumentException。

我看到的三个解决方案是：

更改界面文档以允许更常规的例外类型。这是不整洁的，我认为这是一个“解决方案”是不可接受的，因为它违背了和记录专门异常类型的目的。否则，我也可以在我的文档中的任何地方写Exception，然后让API用户猜测和/或尝试实际抛出哪一个。
从使用依赖项属性注册的验证值回调中返回false（因此在通过SetValue更改属性值时导致ArgumentException，并在InvalidEnumArgumentException中抛出InvalidEnumArgumentException CLR属性包装器的setter。由于不同的原因，这是不整齐的，因为除了调用GetValue / SetValue之外，CLR属性包装器不应包含它们自己的任何逻辑。它看起来不一致使依赖项属性本身的行为与通过其CLR属性设置器访问它时的行为不同。
在验证值回调中抛出false而不是返回{{1}}。 这是我现在使用的解决方案。

我尝试了第三种解决方案，似乎有效。唯一的缺点可能是丢失了默认的异常消息，但这似乎是较小的邪恶。

我的问题是：从验证值回调中这样抛出是否有任何我不知道的副作用，这会让我（或者更确切地说，我的代码）陷入麻烦？ < / p>

Answer 1

我认为您可以从验证回调中抛出更具体的异常。只是反映了WPF代码，它看起来像这个伪代码：

if (!validateValueCallback(newValue))
    throw new ArgumentException();

因此，如果您的验证回调引发，我无法看到它会如何导致任何问题。

从validateValueCallback投掷时有什么不好的事吗？

1 个答案: