其实这个取决于你要不要对exception进行处理,就比如你写的是通用的sdk或者方法给别人调用,而这时这些sdk里的方法不知道上层是否要根据具体的exception进行UI的展示或者其它操作,这是它就可以throws往上抛,直到有一处的代码要对具体的exception做出处理了,就用try catch处理,如果都不用做处理的话,其实就可以在任何地方进行try catch,只是为了图方便,就统一在最上层catch了,其实这大多还是习惯问题,没有说一定要在哪用throws在哪用try catch的吧
每个模块都有自己的输入输出 你不要把try...catch...finally当做另类来看待,你应该把异常信息当做这个模块的输出来看待就对了! 大老板:"把A给我搞定!" 一把手:"A缺少a,干不了!" 大老板:"我不要听这个,你给我搞定!" 一把手:"把ABC给我搞定!" 小弟:"A缺少a,干不了!" 一把手:"我去把a弄来给你,然后你再试一次!" 小弟:"搞定了!"
[quote=引用 1 楼 kailiang_li 的回复:] 底层代码的话使用throw往上层抛,顶层代码直接try catch。
[quote=引用 21 楼 hemowolf 的回复:] 首先要理解异常到底是个什么 异常其实是程序运行过程中无法预料的事件(这里指非RuntimeException),一旦出现这些事件,你必须要进行处理。比如正在访问 数据库时,数据库服务器当机,导致你的业务被中断。这种情况下,你的系统至少必须要告诉明确地用户这次业务操作是失败的,而在后台中,应该留下错误日志,以便排除故障时留下线索。 如何处理异常,这和你的系统设计方案有关 以三层架构(表现层、业务逻辑层、数据访问层)和前面说的数据库访问失败为例,在你的数据访问层提供了方法: getXXX(); getYYY(); updateXXX(XXX data); updateYYY(YYY data); …… 对异常的处理你可以 1、在你的数据访问层捕捉异常,如果是 getXXX 方法出现异常,返回null,如果是updateXXX 方法出现异常,返回false,在数据访问层记录事务日志,逻辑层根据数据访问层的返回值进行逻辑处理 2、在数据访问层声明抛出异常,由逻辑层进行统一捕捉,并记录错误日志。同样通过返回值,让表现层来决定提供哪些信息给用户 3、其它方式我不常用,当然系统设计也不会只有三层设计一种方式,就不说了 异常处理是一种策略,一旦确定,则应该进行统一规范,不能让各个程序员过于自由发挥 以前做过一个项目,有一个在移动、银联平台之间办理手机充值业务的模块。原本的逻辑简单点说,向银联请求扣费,如果成功,则向移动请求充值,结果写这个模块的老兄,只要是java要求捕捉异常的地方全部加上try...catch,然后继续往下走。结果就是出现大量的扣费不成功,充值成功(运营企业为客户白白充值,但收不到钱);或者扣费成功,但充值不成功引来客户投诉。
62,614
社区成员
307,326
社区内容
加载中
试试用AI创作助手写篇文章吧