深圳建站公司招聘,wordpress企业主题 视频教程,万网上传网站,导航类wordpress主题一、异常的处理
异常处理是领域模型要考虑的一部分#xff0c;原因在于模型的责任不可能无限大。在遇到自己处理能力之外的情况时#xff0c;要采用异常机制报告错误#xff0c;并将处理权转交。异常就是这样一种机制#xff0c;某种程度上#xff0c;它可以保证领域模型…一、异常的处理
异常处理是领域模型要考虑的一部分原因在于模型的责任不可能无限大。在遇到自己处理能力之外的情况时要采用异常机制报告错误并将处理权转交。异常就是这样一种机制某种程度上它可以保证领域模型的纯洁性让其只关注于核心逻辑而不用包含一堆意外情况处理代码。
一领域模型中不要使用错误码
除异常外也可以使用错误码报告意外情况但我们并不推荐这种形式。使用异常要更加灵活方便因为如果使用错误代码你不得不在每一个出错的地方增添一个if语句。不管是对于领域模型还是它的调用者来说这都是个坏消息。而异常可以使我们的代码更简洁遇到问题抛出即可。同时它可以包含丰富的领域信息和业务逻辑而不仅仅是语言层面的错误。
另外异常是经过精心定义的方法失败模型因此各种工具如监控可能会随时注意到异常的发生。比如性能监视器会对异常进行追踪统计而错误代码这种形式就没有这些优点。
如果事件是模型的一种特殊逻辑扩展机制那么异常就是一种特殊的意外情况处理机制。虽然它们不像其他模型成员那么直观易懂但它们对于保持模型的纯洁性和扩展性有着不可替代的作用因此我们在建模时应予以考虑。
(二)自定义异常
使用好异常的关键在于让它表达一定的领域含义即细分模型不愿处理的条件抛出有领域含义的异常以便让合适的上级调用者找到合适的处理方式。显然“购物车已满”的异常比“数组越界”的异常更容易让调用者知道如何处理。
有些专家建议当语言框架中已有相应异常时不要自己创建异常这适用于语言级别的异常。对于领域层来说自定义异常是领域逻辑的一部分它可以丰富通用语言。相比于错误代码自定义异常能够很自然地被领域专家所理解。
public class FullCartException extends DomainException {private String error;private int maxCount;public FullCartException(String msg){}public FullCartException(String msg){this.error msg;}public String getError(){return this.error;}
}自定义异常可以继承任何语言中已有的异常本例继承自领域异常DomainException基类。
以下是自定义异常的注意点
要避免太深的继承层次一般Exception类即可满足要求。一定要以Exception作为后缀。要使异常可序列化。为了使异常能够跨应用程序和跨远程边界工作这样做是必须的。要把与安全性有关的信息保存在私有的异常中确保只有可信赖的代码才能得到该信息。比如数据库连接抛出的各类异常可能会泄露你的表命名、表结构等信息。可以为异常定义属性这样就能从程序中取得与异常有关的额外信息。
(三) 抛出异常
设计了自定义异常以后接下来就要决定何时抛出它了。何时抛出异常呢
当领域模型不能或不愿处理某些意外情况时此时应该抛出异常将其处理权交给上一级调用者当然如果调用者不愿处理则可以继续向上抛出最后异常可能被抛到应用层这也是很常见的情况。
这里使用了“意外情况”而不是“错误”因为前者更符合实际含义。“不能处理”的原因是领域逻辑并不知道合适的处理方法可能交由他人更合适。“不愿处理”则是考虑到领域模型的纯粹性不适宜放入与领域逻辑不相关的代码。
另外要注意既然领域模型不处理并将处理权转交了那么程序也就无法继续了。任何方法在抛出异常后后面的代码都不会被执行除了finally中的代码。这很好理解因为后面的代码是为正常情况准备的而现在面对的是异常状况自然后面的逻辑也用不到了。
在上面例子的添加购物车商品方法中如果数量超出了购物车的最大容量可以使用throw new FullCartException“购物车已满”抛出异常。抛出异常的注意点如下
在领域模型中要使用异常来处理意外情况而不是错误码。不要在能处理的正常流程中抛出异常。要为所有的自定义异常构建一份文档使开发人员能够掌握让他们能使用最合理、最具针对性的异常比如不要使用“集合超容”来描述“购物车已满”。在异常消息中避免使用感叹号和问号。注意异常消息的本地化。
四处理异常
处理异常使用的是try…catch…finally代码结构在catch块中处理try块可能抛出的异常另外finally中的代码在遇到异常后也会被执行这也是一种保护机制一般要在其中释放一些占用的资源。
要注意如果你不想处理该异常大可不必捕获可允许异常沿着调用栈向上传递。捕获特定异常的语法是catch(fileNotFoundException e)不要省略括号这部分也不要捕获Exception基类因为这会捕获所有异常通常是没必要的而且可能吞掉有用的异常信息而让软件行为或交互变得奇怪。
比如商品添加不到购物车内用户却得不到任何提醒。定义合适的富有领域逻辑的异常并在模型遇到意外情况时及时抛出是完成领域模型设计并保证其纯洁性的重要工作。
定义合适的富有领域逻辑的异常并在模型遇到意外情况时及时抛出是完成领域模型设计并保证其纯洁性的重要工作。
二、异常的分层
不管是遵循分层架构还是菱形对称架构都可以针对异常划分层次并通过为异常建立统一的层超类来统一对异常的处理。
领域层的异常层超类为DomainException应用层的异常层超类为ApplicationException网关层不需要考虑自定义异常因为它的实现代码抛出的异常属于访问外部资源的基础设施框架。
领域层通过自定义异常表现领域校验逻辑与错误消息到了应用层又保证了异常的统一性。
在编写领域层的代码时对异常的态度为“只抛出不捕获”将所有领域层的异常带来的错误和隐患都交给外层的应用服务。应用服务对待异常的态度迥然不同采用了“捕获底层异常抛出应用异常”的设计原则。
一应用异常
为了让应用服务告知远程服务调用者究竟是什么样的错误导致异常抛出可以分别为应用层定义如下3种异常子类均派生自ApplicationException类型
ApplicationDomainException由领域逻辑错误导致的异常ApplicationValidationException由输入参数验证错误导致的异常ApplicationInfrastructureException由基础设施访问错误导致的异常。
遵循了分层的异常设计原则后可以考虑将异常的层超类定义为非受控异常RuntimeException的子类如此就可以避免异常对接口方法的污染。
建议将应用接口、应用模型、应用异常等均放在API包中因为应用模型和异常也是API的一部分
二自我验证
如果验证逻辑相对复杂就建议将验证逻辑的细节提取到一个私有方法validate()确保构造函数的实现更加简洁。
例如一个代表邮政编号的ZipCode值对象
public class ZipCode {private final String zipCode;private ZipCode(String zipcode){validate(zipcode);this.zipCode zipcode;}private void valideate(String zipCode){if(isEmptyOrNull(zipcode)) throw new InvalidZipCodeException(邮政编码不能为空);if(!isValid(zipcode)) throw new InvalidZipCodeException(邮政编码需要是有效的);}
}自我验证方法保证了值对象的正确性。如果我们将每个组成实体属性的值对象都定义为具有自我验证能力的类就可以使得组成程序的基本单元变得更加健壮间接提高了整个软件系统的健壮性。值对象的验证逻辑是领域逻辑的一部分我们应为其编写单元测试。
自我验证的领域行为仅验证外部传入的设置值。倘若验证功能还需求助外部资源例如查询数据库以检查name是否已经存在这样的验证逻辑就不再是“自给自足”的不能交由值对象承担。
三、异常处理的错误模式
(一)异常淹没
程序捕获某种异常但未对异常 进行正确处理导致异常信息淹没。
1.忽略异常
忽略异常对异常不作任何处理忽略异常处理会使程序泄露意想不到的状态信息。
try(FileInputStream is new FileInputStream(name)){}
catch(FileNotFoundException e){}2.异常消失
异常消失Java支持try/finally语法。若finally模块包含return语句则会抑制异常的抛出使异常丢失。
try{throw new MagicException();
}finally{if(retrunFromFinally())return;
}3.不使用具体的异常
不使用具体的异常在方法中不抛出适当的异常而是普通的Exception或者Throwable会导致异常淹没。因多数异常都直接或间接从java.lang.Exception派生catch(Exception e)处理几乎所有异常。普通的异常使调用者无法确定发生异常的具体种类。
try{
...
}
catch(Exception e){
e.printStackTrace();
}(二)异常使用不当
程序捕获所有异常是个好想法但太广泛地捕获异常或对其使用不正确则会影响程序执行效率甚至威胁程序的安全。
1.使用程序捕获 NullPointerException、0utMemoryError等非检查异常。
try{
method();
}
catch(NullPointerException npe){}2.unlock位置不当
在try内部发生异常以致unlock()无法调用上锁后不释放引起死锁。正确处理是在finally中显式释放。
public class MyClass {private final ReentrantLock lock new ReentrantLock();private int sharedResource 0;public void incrementSharedResource() {lock.lock(); // 上锁try {// 模拟一些可能抛出异常的操作if (sharedResource 0) {throw new IllegalStateException(Shared resource cannot be negative);}sharedResource;// ... 其他操作 ...} catch (IllegalStateException e) {// 异常处理但没有释放锁System.err.println(Exception occurred: e.getMessage());// 注意这里我们忘记了释放锁}// 如果异常在try块中发生lock.unlock()将不会被调用导致死锁}
}3.控制流中使用异常
异常只用在异常条件下 不能用于正常的控制流 。将异常用于控制流会降低代码可维护性和可读性 。
try{Iterator i collection.iterator();while(true){Foo foo i.next();...}
}
catch(NoSuchElementException e){...}
