开发者社区> 问答> 正文

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

java异常一般怎么处理呢?
1 有没有合适的封装?
2 对于catch异常return null这样做有什么弊端。
3 比如io异常要怎么处理。
4 怎么同时代码简洁程度和程序的健壮度。
提出这个几个开放的问题,希望得到大牛的回答。
工作中遇到太多异常处理不好埋坑的同事,有时都不知道是自己太强人所难还是他们水平太低。

展开
收起
1035302957750994 2019-01-30 23:30:04 3532 0
7 条回答
写回答
取消 提交回答
  • 这个问题不是异常处理应该怎么处理的问题,而是针对不同的场景应该怎么处理,我理解的做到以下两点就可以了:
    1.对外提供的服务,不要制造"惊喜"
    2.内部使用的服务,要易于定位问题
    根据使用场景想一下使用你接口的人怎么使用以及出现问题的时候,你要怎么定位问题;就可以知道这个问题怎么解决了

    2019-07-17 23:27:23
    赞同 展开评论 打赏
  • 业务层的异常直接网上层传有时候并不是很好,有些异常很难理解,上层也不知道该怎么处理或者提示给用户,一般会有一个专门的result对象将错误原因描述之后返回,相对友好一些。

    2019-07-17 23:27:23
    赞同 展开评论 打赏
  • 常见的web项目,在service层及以下try catch已知异常并合理处理并记录,对于不可预见的异常向上抛出,在controller最外层统一对异常进行try catch处理,包括错误码及错误描述的封装等等。
    异常处理的原则:能预见并能够处理的及时try catch处理,其他的异常建议继续向外抛出。在逻辑的最外层做一层统一异常处理层。

    2019-07-17 23:27:23
    赞同 展开评论 打赏
  • Java异常是一个非常重要的Java基础设施,很多业务系统依赖异常来做流程控制,不管是不是理想的设计,但是很有效果,根据我的经验,为这些问题来给一些输入。

    1 有没有合适的封装?

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

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

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

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

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

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

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

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

    2019-07-17 23:27:23
    赞同 展开评论 打赏
  • 技术源于生活

    说几个自己经常用的方法
    写代码过程中异常的主要来源: 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 提示未找到数据的设计吧

    2019-07-17 23:27:23
    赞同 展开评论 打赏
  • 什么都感兴趣?

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

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

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

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

    2019-07-17 23:27:22
    赞同 展开评论 打赏
滑动查看更多
问答排行榜
最热
最新

相关电子书

更多
Spring Cloud Alibaba - 重新定义 Java Cloud-Native 立即下载
The Reactive Cloud Native Arch 立即下载
JAVA开发手册1.5.0 立即下载