chengzh

@CRUD 直接写一个这样的全局异常处理器的话 异常是从 service 抛出一直抛到 spring 的 disPathServlet 再回调过来，不如上层搞一个函数可以省去这个步骤。

````java
@RequiresRoles(roles = {RoleEnum.ADMIN_CENTER, RoleEnum.ADMIN_AREA, RoleEnum.ADMIN_CITY})
@ApiOperation(value = "新增费用录入")
@PostMapping("/saveCost")
public Response<Boolean> save(@ApiIgnore @ModelAttribute DmaSalaryEmpInfo empInfo, @RequestBody AddCostVO vo) {
return action(vo, v -> costService.saveCost(empInfo, v));
}
````
这是我目前配合上面的函数接口的使用方式，这样子异常在 service 层出来以后直接就被 action 函数消化了，不然会一直往上面的调用站抛，直到 spring 回调你的异常处理器。 既避免了 性能问题，也解决了代码不优雅的问题。

`异常不要用来做流程控制，条件控制` 本来就是个伪命题, 像是 springaop 里面的事务回滚也是依赖抛异常来做的，
参考 spring security oauth 这些框架当密码不匹配，没有权限，它们也是以异常的形式通知上层的。
这没有什么问题。
我认为阿里上面说的 `异常不要用来做流程控制` 是有前提的 应该是指的 dubbo rpc 接口 要 try 起来以 errcode 和 errormsg 的形式返回。这里面除了性能的考虑之外还有一个很重要的原因是方便理解定位错误的原因吧。

而且楼上所说的 errorcode msg 就要层层 if else 一坨屎一样。其实这个也是很优雅的。
比如 函数语言里的 Either
````scala
def divideBy2(x: Int, y: Int): Either[String, Int] = {
if(y == 0) Left("Dude, can't divide by 0")
else Right(x / y)
}

divideBy2(1, 0) match {
case Left(s) => println("Answer: " + s)
case Right(i) => println("Answer: " + i)
}
````
如果是 java 也是可以做到类似效果的:
````java
public class BaseController {

private Logger logger = LoggerFactory.getLogger(BaseController.class);

/****
* 验证参数 执行函数返回及结果
* @param vo 封装参数的 vo
* @param fun 执行业务方法的函数
* @param <V> vo 类型
* @param <R> 业务函数返回类型
* @return
*/
public <V, R> Response<R> action(V vo, Function<V, R> fun) {

return Try.of(() -> {
if (vo != null) {
String vstr = ValidatorUtils.validate(vo);
if (StringUtils.isNotBlank(vstr)) {
return new Response(ResponseStatus.BAD_REQUEST.getCode(), vstr);
}
}
R result = fun.apply(vo);
Response<R> respOnse= new Response(ResponseStatus.OK.getCode(), ResponseStatus.OK.getMsg());
response.setData(result);

return response;
}

).recover(e -> {
logger.error("", e);
Response<R> respOnse= GlobalControllerExceptionHandler.resolveExceptionCustom(e);
return response;

}).get();


}}
````