把"重试"抽象出来做个工具类…
2020-02-14 16:01:18来源:博客园 阅读 ()
把"重试"抽象出来做个工具类吧
背景介绍
我们在工作中难免会写一些重复性的代码,所以需要我们具备一定的抽象能力,比如把共同的逻辑抽取到抽象类中,也可以通过一些工具类来避免冗余代码
今天这篇文章就是把一个调用服务的重试功能抽取出一个工具类,以备复用。这里为了方便介绍,把调用服务简化成方法的调用,被调用的 foo 方法如下:
public static List<String> foo() {// 没有显示抛出异常
System.out.println("调用方法");
// 模拟抛出异常
System.out.println(1/0);
List<String> list = new ArrayList<>();
list.add("1");
return list;
}
调用方和重试逻辑如下:
List<String> result = null;
// 重试次数
int retryCount = 0;
// 调用服务的开关,默认打开
boolean callSwitch = true;
// 只要调用服务开关开着,并且重试次数不大于最大的重试次数,就调用服务
while (callSwitch && retryCount <= 3) {
try {
// 调用服务
result = foo();
// 省略了对结果的校验,假设到了这里就说明没有问题,把调用服务开关关掉
callSwitch = false;
} catch (Exception e) {
// 发生了异常(比如超时,就需要重试了)
// 调用服务的开关打开
callSwitch = true;
retryCount++;
}
}
// 后面对 result 进行处理
其实上面的代码就已经解决了,服务重试的逻辑,测试没有问题后,可以提交代码让同事帮忙进行 CR 了,可是小朋同学看到这个代码后,给了建议:
可以抽象一层,提出一个 retry 的工具类,这样大家都可以简单复用你的 retry 逻辑
抽象思考过程
白牙心想,也对哈,那就提出一个工具类吧,可是发了会儿呆,竟然没有头绪(反映出了抽象能力的薄弱,平时要多注意抽象能力的培养)。小朋见状,给了一点提示,白牙立马在键盘上噼里啪啦敲击了起来,就有了下面的工具类
主要依赖函数式接口 Supplier 和 BiFunction
public class RetryUtil {
public static <T> T retry(int maxRetryCount, Supplier<T> supplier, BiFunction<T, Exception, Boolean> consumer) {
T result = null;
Exception exception = null;
int retryCount = 0;
boolean callMethod = true;
while (callMethod && retryCount <= maxRetryCount) {
try {
// 获取调用服务的结果
result = supplier.get();
} catch (Exception e) {
// 如果重试次数不小于最大重试次数,就抛出异常,我们把对异常的处理交给业务方
if (retryCount >= maxRetryCount) {
throw e;
}
exception = e;
}
// 对结果进行判断
callMethod = consumer.apply(result, exception);
if (callMethod) {
retryCount++;
}
}
return result;
}
}
业务调用方的代码如下:
List<String> result1 = retry(3,// 最大重试次数
()-> foo(),// 调用服务
(list, e) -> e != null || list == null || list.isEmpty());// 对结果处理
自测没有问题后,又提交代码让小朋给 CR 一下,小朋凝视了会儿,就有了下面的对话
小朋:“retry 方法没有抛出异常”
白牙:“被调用的服务没有显示的抛出异常,这里也就没有抛出”
小朋:“那人如果有服务方显示抛出异常呢?”
白牙:“我再改一版”
服务方显示抛出了异常,这样 retry 方法也得显示抛出异常,但调用方就会显示会处理的异常,如下所示:
public static List<String> foo() throws Exception{// 显示抛出异常
System.out.println("调用方法");
// 模拟抛出异常
System.out.println(1/0);
List<String> list = new ArrayList<>();
list.add("1");
return list;
}
public class RetryUtil {
public static <T> T retry(int maxRetryCount, Supplier<T> supplier, BiFunction<T, Exception, Boolean> consumer) throws Exception{
// 省略...
}
出现这种情况是因为 Supplier 的 get 方法没有抛出异常
@FunctionalInterface
public interface Supplier<T> {
/**
* Gets a result.
*
* @return a result
*/
T get();
}
既然你不支持,那就自己写个呗,于是就有了下面的 DspSupplier,它和 Supplier 的主要区别就是在 get 方法中显示抛出了异常
@FunctionalInterface
interface DspSupplier<T> {
/**
* Gets a result.
*
* @return a result
*/
T get() throws Exception;
}
于是 retry 方法就变成了下面这样子
public class RetryUtil {
public static <T> T retry(int maxRetryCount, DspSupplier<T> supplier, BiFunction<T, Exception, Boolean> consumer) throws Exception{
// 省略...
}
使用了自定义的 Supplier 后,调用方就没有 “Unhandled exception” 了
总结
我们平时再开发的过程中,可以尝试去利用函数式接口去实现一些逻辑的抽取,做成一个工具类,供大家使用,简化人力,也是对自己编码能力的一个提升。
上面的案例比较简单,但麻雀虽小,五脏俱全,也是一个不错的体验
欢迎关注公众号 【每天晒白牙】,获取最新文章,我们一起交流,共同进步!
原文链接:https://www.cnblogs.com/dingaimin/p/12306409.html
如有疑问请与原作者联系
标签:
版权申明:本站文章部分自网络,如有侵权,请联系:west999com@outlook.com
特别注意:本站所有转载文章言论不代表本站观点,本站所提供的摄影照片,插画,设计作品,如需使用,请与原作者联系,版权归原作者所有
- postfix&dovecot搭建邮件服务器 2020-05-30
- Linux服务器内存监控—每小时检查&超出发送邮件& 2020-04-27
- CentOS 7 LAMP搭建并且部署sqli-labs 2020-04-11
- [apue] apue_db:一个可以充当"注册表"的 2020-04-10
- linuxmint 更新管理器消失、面板里打不开('gi.repos 2020-04-09
IDC资讯: 主机资讯 注册资讯 托管资讯 vps资讯 网站建设
网站运营: 建站经验 策划盈利 搜索优化 网站推广 免费资源
网络编程: Asp.Net编程 Asp编程 Php编程 Xml编程 Access Mssql Mysql 其它
服务器技术: Web服务器 Ftp服务器 Mail服务器 Dns服务器 安全防护
软件技巧: 其它软件 Word Excel Powerpoint Ghost Vista QQ空间 QQ FlashGet 迅雷
网页制作: FrontPages Dreamweaver Javascript css photoshop fireworks Flash