你在 Java 里用 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 对象或者其他)来判断还是是依靠抛异常来协商了(类似防御式编程类的官样话)，这太灵活了，还是看团队如何约定的。

• 資深大佬 : orm

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

• 資深大佬 : cshijiel

  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 的异常处理机制了