我有一种情况，我们的开发人员想要在我们所有的应用程序中向前推送System.ComponentModel.DataAnnotations.ValidationExceptions。一个例子是用户将错误的数据输入到表单中，我们的业务逻辑层抛出一个ValidationException，它在调用层处理。
但是，我担心这个异常类是在脱离上下文的情况下使用的，有一天我们会使用一些使用这个异常的动态数据控件，并且很难区分它的制作时间。使用ValidationException与动态控件引发异常的时间。
我们已经使用了一个名为“OurCustomException”的自定义异常类，我认为最好只是将其子类化并创建一个OurCustomValidationException类。这样可以明确区分不同类型的异常。
有什么意见吗？
答案 0 :(得分：9)
......很难说出来 他正在制作时的区别 使用ValidationException vs. 动态控件引发的次数 例外。
我认为这是你做出决定时应该注意的要点。
您似乎暗示上述（无法将您自己的异常与“平台”验证异常区分开来）是一件坏事。情况不一定如此。如果您使用ValidationException 排除来表示验证错误，那么您的所有代码都可以以相同的方式正确处理您自己的和平台异常。不需要自定义平台异常。
在我看来，这是一场胜利。如果您同时将CustomException和ValidationException返回到您的顶层，出于同样的原因，您将不得不以某种方式重复某些逻辑。这是一件坏事（更多的维护，更多的机会悄悄进入）。
所以我的观点是，使用平台ValidationException可能是一种很好的方法，只要你使用严格来传播验证问题。
还要考虑一下你将部分代码提供/出售给第三方的情况（说它真的很酷，你用它制作产品）。如果你的模块抛出“标准”异常（他们可以轻松地集成它）而不是特殊情况下你的模块的所有接口代码，那么第三方可能会更容易。同样，这只有在您坚持使用标准模块抛出ValidationExceptions的情况时才有效。
让我们反过来看看它。你说：
我们的业务逻辑层抛出ValidationException
这就是为什么我将严格和完全放在上面。您需要确保同意验证错误。让我们看看两个假设的问题：
对于1.，问题是简单/预期的输入验证错误。 但在我看来，2。不是。这是一个业务逻辑问题。您可以将其称为验证问题（在交易中，在借记之前，您“验证”是否有足够的可用资金）但我会说它在语义上非常不同。
我建议不要将这两种类型的错误放在相同的异常“包”中，因为它们具有非常不同的含义，并且可能（通常）导致不同的应用程序流逻辑。 （通过以上两个例子，1。应该保持用户与任何其他“拼写错误”类型的问题完全相同，但2.应该让他到一个允许他重新填充帐户的页面。）< / p>
总结一下：使用标准异常对我来说似乎是一个好主意，只要你坚持其预期的语义。