使用ValidationException类

Question

我遇到了一种情况，就是我们的一个开发人员想要制定一个标准，在所有的应用程序中加入System.ComponentModel.DataAnnotations.ValidationExceptions。例如，用户将不良数据输入表单，我们的业务逻辑层抛出在调用层处理的ValidationException。

但是，我担心这个异常类是脱离上下文使用的，而且有一天我们将使用一些动态数据控件来使用这个异常，并且很难区分他使用ValidationException时与动态控件引发异常的时间之间的区别。

我们已经使用了一个名为"OurCustomException“的自定义异常类，我认为最好是将其作为子类，然后创建一个OurCustomValidationException类。这样，不同类型的异常就可以被清楚地切割。

有什么意见吗？

Answer 1

...很难区分他何时使用ValidationException与动态控件引发异常的时间之间的区别。

我认为这是你在作出决定时应该考虑的要点。

您似乎暗示，上述(无法区分您自己的异常和“平台”验证异常)是一件坏事。不一定是这样的。如果您使用ValidationException 专用来表示验证错误，那么您的所有代码都可以以同样的方式正确地处理您自己的和平台的异常。不需要特殊情况的平台例外，自定义的。

在我看来这是一场胜利。如果您让CustomException和ValidationException都回到您的图层层，原因是相同的，那么您将不得不以某种方式重复一些逻辑。这是一件坏事(更多的维护，更多的错误出现)。

因此，我的观点是，使用平台ValidationException可能是一个很好的方法，只要您严格使用它，，，用于传播验证问题。

还可以考虑将代码的一部分提供/出售给第三方的情况(比如，它很酷，您可以用它制作一个产品)。如果您的模块抛出“标准”异常(它们可以很容易地集成)，而不是必须为您的模块专门处理他的所有接口代码，那么第三方可能会更容易。同样，只有在标准模块抛出ValidationExceptions的情况下，这才是有效的。

让我们从另一个角度看它。你说：

我们的业务逻辑层抛出一个ValidationException

这就是为什么我把严格地放在和上面，只放在上面。您需要确保您同意什么是验证错误。让我们看看两个假设的问题：

• insufficient

1. "abc“不是此操作的有效数字

。

对于1.问题是简单/预期的输入验证错误。但在我看来，2不是。这是一个业务逻辑问题。您可以将其称为验证问题(在事务中，在借方之前，您可以“验证”是否有足够的可用资金)，但我认为它的语义非常不同。

我建议不要将这两种类型的错误放在同一个异常“袋子”中，因为它们有着非常不同的含义，并且可能(经常)导致不同的应用程序流逻辑。(对于上述两个示例，1.应该让用户保持在完全相同的表单上，就像任何其他“错误”类的问题一样，但是2.应该会让他进入一个允许他重新填充帐户的页面。)

总之:使用标准异常对我来说似乎是个好主意，只要您坚持它的预期语义。