[@talishboy][¥20]java异常处理分水岭怎么看。

这个问题不是异常处理应该怎么处理的问题，而是针对不同的场景应该怎么处理，我理解的做到以下两点就可以了：
1.对外提供的服务，不要制造"惊喜"
2.内部使用的服务，要易于定位问题
根据使用场景想一下使用你接口的人怎么使用以及出现问题的时候，你要怎么定位问题；就可以知道这个问题怎么解决了

业务层的异常直接网上层传有时候并不是很好，有些异常很难理解，上层也不知道该怎么处理或者提示给用户，一般会有一个专门的result对象将错误原因描述之后返回，相对友好一些。

常见的web项目，在service层及以下try catch已知异常并合理处理并记录，对于不可预见的异常向上抛出，在controller最外层统一对异常进行try catch处理，包括错误码及错误描述的封装等等。
异常处理的原则：能预见并能够处理的及时try catch处理，其他的异常建议继续向外抛出。在逻辑的最外层做一层统一异常处理层。

Java异常是一个非常重要的Java基础设施，很多业务系统依赖异常来做流程控制，不管是不是理想的设计，但是很有效果，根据我的经验，为这些问题来给一些输入。

1 有没有合适的封装？

一般公司会结合自己业务系统的错误码结合来设计异常，每个异常的实例会包含一个错误码，错误码和异常之间可以互相转换。

2 对于catch异常return null这样做有什么弊端。

这种做法不好，异常不要吃掉，要不处理掉，要不抛出。

3 比如io异常要怎么处理。

可以优先考虑临时问题重试，或者对IO问题进行描述，影响范围等进行抛出。

4 怎么同时代码简洁程度和程序的健壮度。

代码其实不怕多，只要合理、清晰就可以，异常处理其实就是为了逻辑处理的代码保持简洁，试想一下没有异常的语言，如果深层次返回一个错误，需要层层退出，效果是很繁琐的。

提出这个几个开放的问题，希望得到大牛的回答。
工作中遇到太多异常处理不好埋坑的同事，有时都不知道是自己太强人所难还是他们水平太低。

说几个自己经常用的方法
写代码过程中异常的主要来源: I/O,调用框架,java基础库，RPC超时，数据库连接,其他NPE,索引越界....

首先明白你写的代码的，写出来是要对这个代码负责的，出了问题怎么能快速的定位问题呢?

1. 在和别的系统/框架/底层库交互的边界处, 加一层try,catch, 出错了记录日志(param,result,exception)，确保这些数据出错了能够返回empty,而不是null,不会污染到自己的处理逻辑.
2. 在自己的代码中合理利用Optional类来判断null,规避很多NPE,代码也相对简洁了
3. 在自己接口的边界处,加一层大的try.catch1：记录你自己检查出来的参数检查错误,或者可以在逻辑处理过程中不用再处理可以直接 返回的错误; catch2( Throwable e):记录你未预知到的错误,并记录到特定的日志文件.

有了上面三点: 有任何问题都方便排查了
ps,在他人接口或者自己接口边界上注意success but empty, 和failed but msg 提示未找到数据的设计吧

总结下发生异常后的能做的事情：

1 - 不捕捉，直接crash
2 - 完全捕捉，不做任何处理，return whatever normal value (true/false/null/ "")
3 - 向上抛，直到在某适合的一层捕捉
分为两种情况，
　－直接返回给用户错误，建议重试或者反馈，同时记录异常操作记录
　－在某一层次上忽略这个异常，但是记录异常操作到日志

异常抛多高，或者是否需要记录到日志，或者忽略，这个尺度由业务决定，比如查询数据库类的，可以建议重新尝试，如果是交易类的，交易已经发起，但未返回最终确认，需要返回订单号，建议稍后按订单号查询，具体情况具体分析。

可以参照 effective java里面的建议
1.尽量用runtime异常而不用checked异常，防止污染接口
2.异常是错误分支，catch返回null说明走的是正常返回，错误需要有专门的错误码返回给客户
3.底层异常可以在上层封装，作为调用者不需要关心所有异常，主要关心被调用者返回的异常即可
4.catch异常是处理20%的异常情况，但是并不意味着不重要，如果觉得catch里面的内容太多影响阅读，可以考虑函数抽取，保持try，catch结构里面的内容简单