你在 Java 里用 try-catch 多不？

[NoKey]

为了避免可能出现的异常

我们这里大部分方法都用 try-catch 括起来

看起来很难看啊。。。

比如，接收页面传入的整数，传过来是字符串，我们需要用数字的时候，就会 Integer.valueOf()

但是，写页面的人不是同一个，也可能经常换，也可能不同项目组

虽然有文档，但是，不能确保一定会传入整数

为了在可能出问题的时候不会出问题而背锅，我们就需要用上 try catch

有大佬会说使用前验证参数

有时候参数很多，每个都去验一次么？

各位大佬有啥好方法么？😄

[FanError]

现在我都是 throw RuntimeException 了，然后全局异常捕获，统一返回报错信息

[luckyrayyy]

楼上+1，直接抛，全局补

[zhuangzhuang1988]

<Java8 实战>里这样扯过 P217
public static Optional<Integer> stringToInt(String s) {
try {
return Optional.of(Integer.parseInt(s));
} catch (NumberFormatException e) {
return Optional.empty();
}
}
然后再应用

PS: 其实 C#很早就有函数 tryParse https://docs.microsoft.com/en-us/dotnet/api/system.int32.tryparse?view=netframework-4.8

[yjxjn]

@luckyrayyy 这个全局补怎么说？比如调用某工具类里方法全部抛出异常，然后再调用的 Controller 里面接么？能详细说一下吗？

[luckyrayyy]

@yjxjn ExceptionHandler 注解

[asd123456cxz]

@yjxjn 如果是 Spring 项目，可以新建一个异常处理类，使用 @ControllerAdvice 注解，默认使用 AOP 构造出针对全部 controller 的代理类，全局处理异常。不过自己写一个切面部分地处理也可以，顺便把日志统计也做了

[Jrue0011]

Spring MVC 的话，Controller 加 Validated 注解，MVC 本身参数绑定自带的校验再加上校验注解，支持简单参数、Form 对象和 RequestBody 对象，进入方法前入参就校验完了，ControllerAdvice 捕获校验异常统一返回 SmartValidator 格式化后的校验结果，还支持国际化。。。

[superrichman]

所有传入的参数都要验证。可以搜搜 java form validation，不需要自己写一堆 try catch

[Jrue0011]

@Jrue0011 另外这样校验也支持分组。。就是入参是同一个 bean 类，这个接口只校验某几个属性，另一个接口校验另外一些属性

[limuyan44]

全靠全局捕获，自己基本不会用，项目里每个 controller 里面写过 trycatch return 一个自定义 response 我都感觉这帮人没正经学过 spring mvc,框架安排的明明白白的，不需要自己做这种丑陋的写法

[optional]

lombok

[loryyang]

Spring MVC 直接支持了啊，都不需要你来处理，包括类型和空判断

[zhuawadao]

@ControllerAdvice

[araaaa]

let it crash

[xuanbg]

一般都是直接抛，然后全局捕获。只有确定需要处理的异常，才 try/catch 起来自己处理掉异常。譬如处理队列消息的时候，异常了要写回死信队列，以免丢消息。

[paragon]

关键字 JSR349 ControllerAdvice

[mawerss1]

强烈反对上面的把异常 catch 掉返回空值的做法，破坏了语义甚至可能产生一些发现不了的逻辑问题，如果非要 catch，建议再向上层抛出一个定义异常

[oneisall8955]

这种运行时的，不用管吧，前端传过来错误的，不按照接口定义写，肯定是对方的问题，不是我的问题为啥要管呢

[sagaxu]

crash early
crash often

[yanyueio]

和楼上观点大概类似:

* Java Core: 避开 checked 异常这类编译时就强迫你处理的异常，其他异常 let crash 。
* 框架: 比如 Spring 系，全局处理，而且搭建架子的负责人应该会提前制定好规范&模板了。

至于说入参的检验，那要看大家约定的是依靠返回值(json 对象或者其他)来判断还是是依靠抛异常来协商了(类似防御式编程类的官样话)，这太灵活了，还是看团队如何约定的。