9
回答
关于项目中java异常的处理
终于搞明白,存储TCO原来是这样算的>>>   

大家在做项目的时候对异常是怎么处理的:

1、原样抛出还是不抛出?

2、原样抛出还是转化为自定义的异常?

3、如果有多个异常是放到一个try...catch块里面还是放在多个?

4、如果有异常,例如:SQLException是抛出SQLException还是抛出Exception?

5、怎样抛出异常才是更合理的呢?

举报
四火
发帖于4年前 9回/451阅
共有9个答案 最后回答: 4年前

1.dao service 中大多数据库异常 checked 变 runtime 

2.登陆权限 用多种不同的异常跳转不同的逻辑,所以需要自定义异常

3.多个非checked异常用自动生成的多个看着放心

4.用runtimeexception 抛出,在 action 以上 去作转向或 处理

5.把他当作一个goto语句....应该是最合理的想法 (如果有其它方案,最好不使用)

关于异常我的经验是:
1)在模块的顶层(外部接口层 or 表现层)做异常捕捉,内层不做。
比如一个内层的方法参数要做空指针判断吗?我的回答是不必要。
2)自定义异常用在业务逻辑中。有利于方法的快速返回。
比如游戏中要求等级达到39级才可以进入某区域,当角色等级不满39级时,可以使用自定义异常抛出。

有两种情况下不建议抛出异常:
1)对性能要求比较苛刻的情况下
2)执行一个连续反复且不希望被打断的任务时。比如加载展示一个文件列表但其中一个文件不存在时。
此时建议自己处理异常并对顶层做异常通知。


  1. 当你捕获一个异常你首先要了解这个异常代表什么含义。通常,JDK 和多数开源框架都会对异常做详细的描述。然后你再根据这些描述判断你是否需要处理这些异常,如何处理。
  2. 重新封装异常通常用在你想对checked exception做统一处理的时候,将其封装成另外一个自定义的runtime exception。然后再通过UncaughtExceptionHandler或者框架提供的异常处理机制做统一的处理。
我的想法是,自己能处理的异常就自己处理,不能处理的有两种方式,一种方式是记录日志,第二种就是向外抛了,千万不能什么都不做或者只打印在控制台,还有一个想法是,在最外层的异常不能乱抛,想想12306就被数以万计的码农吐槽,因为从异常堆栈里面有可能暴露系统的核心数据或者技术,况且一般的人又看不懂那些东西,抛出来做什么?为了查找问题的话,记录日志就好了
--- 共有 10 条评论 ---
littledoo回复 @郭銳 : 我说得已经够清楚了,但是我说服不了你。你的观点是“该抛的抛,不该抛的不抛”,很明显,这句话万无一失,怎么说都是对。但这个论点笼统到没有任何现实的意义,怎么说都是对。所以我觉得讨论只是浪费时间,你关注的只是自己的面子,而不是问题本身。还有,最后那一句“抛到外层就不能抛了”这句话很多余,但透露出你的软弱,关于这贴,我真的不会再回了,您如果有兴趣,可以重设论题,到时我们再来讨论。祝好! 4年前 回复
guor回复 @littledoo : 伙计,观点是拿出来讨论的,别一副不情愿的样子,我的观点不一定对,只要有人能说服我! 4年前 回复
littledoo@郭銳 哎…祝好:)拜拜 4年前 回复
guor回复 @littledoo : 你始终没看明白我的意思,我的观点还是,能处理的异常就自己处理,不能处理的异常就往外抛,最外层的异常我的意见只能记日志,不能再抛了! 4年前 回复
littledoo回复 @郭銳 : 笑了。。So?你的意思是?异常要往外抛?呵呵 OK,我把我的观点做个结尾,不会在回了: 异常应该直接抛出至处理异常的顶层,而不是在内层处理。我说完了 4年前 回复

自己处理业务相关方面的异常,

其他的异常在高层捕捉然后记录到日志系统里面,方便管理员查阅。

1、非业务异常 和算法异常截取, 业务异常 service 抛出

2、如需 更快, 或有自定义 需抛出的异常才会使用, 一般不需要

3、放在一起, 自动会由上而下检查的

4、如果有异常,例如:SQLException是抛出SQLException还是抛出Exception? 自然SQL 异常保持 一致

5、怎样抛出异常才是更合理的呢? ...... 多累积了


视图 - > 控制器 -> 业务逻辑 -> dao 数据处理

比如这种结构,我的方式是,dao层抛出异常,交给业务逻辑处理,业务逻辑层需要执行try...捕获...业务逻辑应当要知道如何处理异常

我的理解是,底层不含业务逻辑部分,不应该处理异常,而是往上抛

顶部