我有这样一种情况，我们的一位开发人员想要制定一个标准，我们在所有应用程序中抛出 System.ComponentModel.DataAnnotations.ValidationExceptions 向前发展。例如，用户在表单中输入错误数据，我们的业务逻辑层抛出一个 ValidationException，该异常在调用层处理。
但是，我担心这个异常类被断章取意地使用，并且有一天我们将使用一些利用此异常的动态数据控件，并且很难区分他何时进行使用 ValidationException 与动态控件引发异常的次数。
我们已经使用了一个名为“OurCustomException”之类的自定义异常类，我认为最好从它继承并创建一个 OurCustomValidationException 类。这样可以明确区分不同类型的异常。
有什么意见吗？
最佳答案
... it will be difficult to tell the difference between when he's making use of the ValidationException vs times that the Dynamic Controls raise the exception.
我认为这是您在做出决定时应该考虑的重点。
您似乎暗示上述情况(无法将您自己的异常与“平台”验证异常区分开来)是一件坏事。不一定如此。如果您使用 ValidationException 专门 来表示验证错误，那么您的所有代码都可以以相同的方式正确处理您自己的异常和平台异常。无需针对自定义平台异常进行特殊处理。
在我看来，这是一场胜利。如果 CustomException 和 ValidationException 都返回到顶层出于同样的原因，则您将不得不以某种方式重复某些逻辑。这是一件坏事(更多的维护，更多的错误潜入的机会)。
所以我的观点是，只要您严格将其用于传播验证问题，使用平台 ValidationException 可能是一个很好的方法。
还请考虑您将部分代码提供/出售给第三方的情况(假设它真的很酷并且您用它制作了产品)。如果您的模块抛出“标准”异常(他们可以很容易地集成它)而不是必须为您的模块特殊处理他的所有接口(interface)代码，那么对于第三方来说可能会更容易。同样，这仅在您坚持标准模块会抛出 ValidationExceptions 的情况下才有效。
让我们反过来看。你说:
our business logic layer throws a ValidationException
这就是为什么我在上面加上strictly 和exclusively 的原因。您需要确保就什么是验证错误达成一致。让我们来看两个假设的问题:
- “abc”不是有效数字
- 本次行动资金不足
对于 1.，问题是简单/预期的输入验证错误。 但在我看来，2. 不是。这是一个业务逻辑问题。您可以将其称为验证问题(在交易中，在借记之前，您“验证”是否有足够的可用资金)但我会说它在语义上非常不同。
我建议不要将这两种类型的错误放在同一个异常“包”中，因为它们具有非常不同的含义，并且可能(经常)导致不同的应用程序流程逻辑。 (对于上面的两个例子，1. 应该让用户保持在同一个表单上，就像任何其他“打字错误”类型的问题一样，但是 2. 应该让他进入一个允许他重新填写帐户的页面。)
总结一下:使用标准异常对我来说似乎是个好主意，只要您坚持其预期的语义即可。
关于c# - 使用 ValidationException 类，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/5082146/