假设我们有数十个Java POJO，它们代表我的域，即系统中的数据作为对象在系统的不同层之间流动。该系统可以是Web应用程序，也可以是简单的桌面应用程序。域的内容并不重要。
在设计系统时，我很困惑应该在哪里放置任何验证逻辑。我的POJO（域对象）表示我的数据，并且这些对象内的某些字段必须遵守某些条件，但是如果我在设置方法中放入了很多验证逻辑，那么告诉调用方客户端的唯一方法是引发异常。而且，如果我不希望系统崩溃，则该异常必须是一个已检查的异常，必须对其进行捕获和处理。这样的结果是，每当我使用setter方法（甚至构造函数）创建一个新对象时，我要么重新抛出该异常，要么使用try-catch块。被迫在许多setter方法上使用try-catch感觉不对。
所以问题是我应该把验证逻辑放在哪里，这样我就不会因大量的样板try-catch块和重新抛出而使我的代码混乱。欢迎最优秀的JAVA字节食用者加入讨论。
我已经进行了研究和搜索，但没有找到关于此主题的任何具体讨论，因此我非常热情地等待，以便对真正应该做的事情有更深入的了解。
您说的时候可能已经回答了自己的问题
这些对象内部的某些字段必须遵守某些条件
考虑系统中的不变量总是有帮助的，例如，您要不惜一切代价维护的事物或必须始终遵循的规则。
POJO是数据对象上此类不变量的“最后防线”，因此是放置验证逻辑的适当（甚至是必要的）地方。没有这种验证，对象可能不再代表您所在领域中有意义的东西。
这些系统不变式在对象（或方法）与其“客户端”之间形成契约。如果有人试图违反（希望有据可查的）合同使用它们，则抛出异常是正确的选择，因为正确使用系统的各个部分是客户的责任。
随着时间的推移，我已经开始有利于unchecked异常检查过那些为合同违约的任何情况，部分原因是你提到的原因，即为了避免try- catch块随处可见。
Java的标准未经检查的异常包括：
最佳做法准则是使用checked异常时，错误被认为是可回收和unchecked异常，否则。
约书亚·布洛赫（Joshua Bloch）的“ 有效Java，第二版 ”的第9章提供了关于该主题的更多知识：
以上任何一项都不应该阻止您在更高级别上使用任何适当的验证逻辑，尤其是强制执行任何特定于上下文的业务规则或约束。
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句