java异常一般怎么处理呢?
1 有没有合适的封装?
2 对于catch异常return null这样做有什么弊端。
3 比如io异常要怎么处理。
4 怎么同时代码简洁程度和程序的健壮度。
提出这个几个开放的问题,希望得到大牛的回答。
工作中遇到太多异常处理不好埋坑的同事,有时都不知道是自己太强人所难还是他们水平太低。
这个问题不是异常处理应该怎么处理的问题,而是针对不同的场景应该怎么处理,我理解的做到以下两点就可以了:
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,索引越界....
首先明白你写的代码的,写出来是要对这个代码负责的,出了问题怎么能快速的定位问题呢?
有了上面三点: 有任何问题都方便排查了
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结构里面的内容简单
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。