你在 Java 里用 try-catch 多不？

[NoKey]

为了避免可能出现的异常

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

看起来很难看啊。。。

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

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

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

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

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

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

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

[orm]

目前我用 try catch 最多的就是在一些定时任务上，避免执行过程终端

[gwybiaim]

1. Bean Validation(JSR380)
2. @ControllerAdvice
3. BizRuntimeException(建议)

[xiaofan2]

@cshijiel BizRuntimeException 是啥？？

[ganning]

@Validated 可以了解一下这个注解

[kanepan19]

有事务的地方抛异常， 没事务的地方都抓，抓了把异常放到 resultMsg 放到 result 里返回。
全局异常肯定有，个人不喜欢随便抛。

[chendy]

工具类里写挺多的，吃掉一些不可能出现的 checked exception （然后抛一个自定义 unchecked exceptoin ），比如加密算法没找到，编码未找到这种…

[yeqizhang]

不是用户填的东西的话，没必要，和前端调通了之后一般没有问题，有问题也是要找为啥数据会错。
如果是用户填的，前端先检验，然后后端也要做检验或者捕获异常，我遇到测试测接口直接传不符合的数据然后提 bug 的

[mosliu]

用 common lang3 的 NUmberUtils 的 toInt 不行么? 错误的转出来个默认值 检查直接返回错误。

[aitaii]

@xiaofan2 继承 RuntimeException 的自定义业务异常，ExceptionHandler 里处理异常信息

[sunxiansong]

插一下嘴。。

之前写 java,try catch 用的不多，反正有毛病都抛出去。

现在写 go, 各种
```go
if err != nil {
return err
}
```
遇到返回结果有 error 的都要这么来一下，复杂点的函数能来好几次

觉得 java 的话，对于需要特别识别的错误，可以检查下，不然就直接抛出吧，大部分正常流程能走通就行

有些函数声明的异常甚至几乎不会出现，追求完善的错误处理覆盖是不现实的，还不如完善错误监控处理机制，避免隐式错误处理、错误遗漏，定期的检查错误情况再完善代码

如果只是不喜欢 try catch 风格，那自己搞一套错误-结果返回方案就行

[EminemW]

我有个疑问，这个抛异常会影响性能吗，之前不知道在哪里看过不要随便抛异常。。我的做法的是 return Result.error(code, msg);

[chanchan]

很多地方需要写，但是懒得写😐

[lihongming]

拿异常当日常反馈的路过。

只要数据不合格就抛异常出去，调用方不 try catch 怎么活啊？

[yukiloh]

以前自己喜欢扔，后来看到哪里说能抓尽量当下抓，不能的再扔，给搞迷糊了

[purensong]

定义一个 @ControllerAdvice 修饰的全局异常处理类，实现多个方法加上 @ExceptionHandler(value = Exception.class)
注解，value 是 Exception 的子类，例如要检查必须的字段传入，用 MethodArgumentNotValidException，具体的字段不能为空用 @NotNull 注解。
这是通用的异常处理，如果还有业务异常，需要自定义异常类，我习惯直接在代码里抛出自定义异常，也都交由全局异常类去特殊处理

[purensong]

可以说代码里 try catch 可能都是连接消息关闭，文件不存在这些代码，很少会出现类型检查这种低级别的捕获，这种检查代码大量存在，而且级别较低，不会有出现异常后的处理，基本就是报错提示到前端就没有了。

[pabno]

1. 从项目整体质量的角度出发，接口约定就应该遵守，如果不是强制约束，即使后端可以兼容这种数据格式，前段指不定也会因为数据格式的不一致而引发新的问题，提前暴露问题会减少修正错误的成本

2. 后端参数验证可以使用校验框架写表达式自动校验，然后统一捕获校验异常返回统一数据

[xiangyuecn]

转换成 int 时，返回 Integer 类型，要么返回一个数要么，返回一个 null，拒绝使用 try catch

byte 统一用 short 类型，拒绝负数 （ doge

[vwym]

web 项目就直接抛出去全局处理了，参数验证可以考虑用 Validations 注解完事。
不做 try catch

[Mystery0]

@EminemW 确实有一点影响，不过照你的这样子返回 Result.error(code, msg)，调用深了以后，每一层都要去做执行结果的判断，写着写着就变成手写 Java 的异常处理机制了