但是,我担心这个异常类是在脱离上下文的情况下使用的,有一天我们会使用一些使用这个异常的动态数据控件,并且很难区分它何时使用它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可能是一个好方法,只要你严格使用它来传播验证问题.
还要考虑一下你将代码的一部分提供/出售给第三方的情况(说它真的很酷,你用它制作产品).如果你的模块抛出“标准”异常(他们可以轻松地集成它)而不是特殊情况下你的模块的所有接口代码,那么第三方可能会更容易.同样,这只有在您坚持使用标准模块抛出ValidationExceptions的情况时才有效.
让我们反过来看看它.你说：
our business logic layer throws a ValidationException
这就是为什么我严格地和完全地放在上面.您需要确保同意验证错误.让我们看看两个假设的问题：
>“abc”不是有效数字
>这项行动的资金不足
对于1.,问题是简单/预期的输入验证错误.
但在我看来,2.不是.这是一个业务逻辑问题.您可以将其称为验证问题(在交易中,在借记之前,您“验证”是否有足够的可用资金)但我会说它在语义上非常不同.
我建议不要将这两种类型的错误放在相同的异常“包”中,因为它们具有非常不同的含义,并且可能(通常)导致不同的应用程序流逻辑. (通过以上两个例子,1.应该保持用户与任何其他“拼写错误”类型的问题完全相同,但2.应该让他进入允许他重新填写帐户的页面.)
总结一下：使用标准异常对我来说似乎是一个好主意,只要你坚持其预期的语义.
