在Java中,在JDK 1.8里也引入了类JavaScript的玩法 —— CompletableFuture
。这个类提供了大量的异步编程中Promise的各类方式。下面例举几个。java
链式处理:编程
CompletableFuture.supplyAsync(this::findReceiver) .thenApply(this::sendMsg) .thenAccept(this::notify);
上面的这个链式处理和JavaScript中的then()
方法很像,其中的 supplyAsync()
表示执行一个异步方法,而 thenApply()
表示执行成功后再串联另一个异步方法,最后是 thenAccept()
来处理最终结果。app
下面这个例子是,合并两个异步函数的结果成一个的示例:异步
String result = CompletableFuture.supplyAsync(() -> { return "hello"; }).thenCombine(CompletableFuture.supplyAsync(() -> { return "world"; }), (s1, s2) -> s1 + " " + s2).join()); System.out.println(result);
接下来,咱们再来看一下,Java这个类相关的异常处理:分布式
CompletableFuture.supplyAsync(Integer::parseInt) //输入: "ILLEGAL" .thenApply(r -> r * 2 * Math.PI) .thenApply(s -> "apply>> " + s) .exceptionally(ex -> "Error: " + ex.getMessage());
咱们要注意到上面代码里的 exceptionally()
方法,这个和JavaScript Promise中的 catch()
方法类似。异步编程
运行上面的代码,会出现以下输出:函数
Error: java.lang.NumberFormatException: For input string: "ILLEGAL"
也能够这样:this
CompletableFuture.supplyAsync(Integer::parseInt) // 输入: "ILLEGAL" .thenApply(r -> r * 2 * Math.PI) .thenApply(s -> "apply>> " + s) .handle((result, ex) -> { if (result != null) { return result; } else { return "Error handling: " + ex.getMessage(); } });
上面代码中,你能够看到,其使用了 handle()
方法来处理最终的结果,其中包含了异步函数中的错误处理。spa
下面是我我的总结的几个错误处理的最佳实践。若是你知道更好的,请必定告诉我。调试
统一分类的错误字典。不管你是使用错误码仍是异常捕捉,都须要认真并统一地作好错误的分类。最好是在一个地方定义相关的错误。好比,HTTP的4XX表示客户端有问题,5XX则表示服务端有问题。也就是说,你要创建一个错误字典。
同类错误的定义最好是能够扩展的。这一点很是重要,而对于这一点,经过面向对象的继承或是像Go语言那样的接口多态能够很好地作到。这样能够方便地重用已有的代码。
定义错误的严重程度。好比,Fatal表示重大错误,Error表示资源或需求得不到知足,Warning表示并不必定是个错误但仍是须要引发注意,Info表示不是错误只是一个信息,Debug表示这是给内部开发人员用于调试程序的。
错误日志的输出最好使用错误码,而不是错误信息。打印错误日志的时候,除了要用统一的格式,最好不要用错误信息,而使用相应的错误码,错误码不必定是数字,也能够是一个能从错误字典里找到的一个惟一的可让人读懂的关键字。这样,会很是有利于日志分析软件进行自动化监控,而不是要从错误信息中作语义分析。好比:HTTP的日志中就会有HTTP的返回码,如:404
。但我更推荐使用像PageNotFound
这样的标识,这样人和机器都很容易处理。
忽略错误最好有日志。否则会给维护带来很大的麻烦。
对于同一个地方不停的报错,最好不要都打到日志里。否则这样会致使其它日志被淹没了,也会致使日志文件太大,最好的实践是,打出一个错误以及出现的次数。
不要用错误处理逻辑来处理业务逻辑。也就是说,不要使用异常捕捉这样的方式来处理业务逻辑,而是应该用条件判断。若是一个逻辑控制能够用if - else清楚地表达,很是不建议使用异常方式处理。异常捕捉是用来处理不指望发生的事的,而错误码则用来处理可能会发生的事。
对于同类的错误处理,用同样的模式。好比,对于null
对象的错误,要么都用返回null,加上条件检查的模式,要么都用抛NullPointerException的方式处理。不要混用,这样有助于代码规范。
尽量在错误发生的地方处理错误。由于这样会让调用者变得更简单。
向上尽量地返回原始的错误。若是必定要把错误返回到更高层去处理,那么,应该返回原始的错误,而不是从新发明一个错误。
处理错误时,老是要清理已分配的资源。这点很是关键,使用RAII技术,或是try-catch-finally,或是Go的defer均可以容易地作到。
不推荐在循环体里处理错误。这里说的更多的状况是对于try-catch这种状况,对于绝大多数的状况你不须要这样作。最好把整个循环体外放在try语句块内,而在外面作catch。
不要把大量的代码都放在一个try语句块内。一个try语句块内的语句应该是完成一个简单单一的事情。
为你的错误定义提供清楚的文档以及每种错误的代码示例。若是你是作RESTful API方面的,使用Swagger会帮你很容易搞定这个事。
对于异步的方式,推荐使用Promise模式处理错误。对于这一点,JavaScript中有很好的实践。
对于分布式的系统,推荐使用APM相关的软件。尤为是使用Zipkin这样的服务调用跟踪的分析来关联错误。