注册依赖项属性时，可以使用overload of Register that accepts a validation callback。
如果该验证回调返回值的false，则将该值分配给依赖项属性将失败，并会抛出ArgumentException，并抱怨无效的属性值。
现在，虽然ArgumentException在某些情况下是适当的类型，但在某些情况下应使用一些特殊的异常类型。特别是，我要声明一个enum类型的属性，要处理不受支持的值，正确的方法是抛出一个InvalidEnumArgumentException。而且，我正在实现一个接口，该接口将enum属性显示为CLR属性，并且在该属性的文档注释中，要求为无效值引发InvalidEnumArgumentException。
我看到的三个解决方案是：
更改接口文档以允许使用更通用的异常类型。这是不整洁的，我认为这是不可接受的“解决方案”，因为它破坏了拥有和记录专门的异常类型的目的。否则，我也可以在文档的任何地方编写Exception，然后由API用户自行猜测和/或尝试实际抛出哪个。
从注册了依赖项属性的验证值回调中返回false（因此，当通过ArgumentException更改属性值并在CLR属性包装器的设置器中抛出SetValue时，会导致产生InvalidEnumArgumentException。这对于另一个原因是，CLR属性包装器除了调用GetValue / SetValue之外，不应包含任何逻辑；与通过CLR属性设置器访问依赖属性相比，依赖属性本身的行为似乎不一致。
在验证值回调中引发InvalidEnumArgumentException而不是返回false。这是我现在使用的解决方案。
我尝试了第三种解决方案，它似乎可以工作。唯一的缺点可能是丢失了默认的异常消息，尽管它看起来不那么邪恶。
我的问题是：从validate值回调中抛出这样的副作用是否会引起我不知道的副作用，而这会给我（或更确切地说，我的代码）带来麻烦？
最佳答案
我认为您可以从验证回调中引发更具体的异常。只是回顾一下WPF代码，它看起来像下面的伪代码：
if (!validateValueCallback(newValue))
throw new ArgumentException();
所以，如果您的验证回调抛出，我看不到它将如何引起任何问题。
关于.net - 从validateValueCallback抛出时，有什么不好的事情发生吗？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/18146576/