java try catch和throws使用场景？怎么合理使用？

[钠离子zi]

项目开发中，大家有没有try catch和throws乱用的现象？
反正我在开发中，随处可见的try catch或者throws，大家貌似并没有统一的标准，导致代码混乱，可读性差，还不知道有没有什么安全隐患。
小弟在此请教，对try catch和throws的使用上，有没有比较好的建议，好让我们的代码更加健壮和优雅。

[半是醉]

我们现在的项目中，一般来说都是持久层和业务层try catch并且throws异常，控制层只是try catch，但不会抛出

[zoeg]

每个模块都有自己的输入输出 你不要把try...catch...finally当做另类来看待,你应该把异常信息当做这个模块的输出来看待就对了! 大老板:"把A给我搞定!" 一把手:"A缺少a,干不了!" 大老板:"我不要听这个,你给我搞定!" 一把手:"把ABC给我搞定!" 小弟:"A缺少a,干不了!" 一把手:"我去把a弄来给你,然后你再试一次!" 小弟:"搞定了!"

[小灰狼]

引用 23 楼 u012259256 的回复:

[quote=引用 21 楼 hemowolf 的回复:] 首先要理解异常到底是个什么 异常其实是程序运行过程中无法预料的事件（这里指非RuntimeException），一旦出现这些事件，你必须要进行处理。比如正在访问 数据库时，数据库服务器当机，导致你的业务被中断。这种情况下，你的系统至少必须要告诉明确地用户这次业务操作是失败的，而在后台中，应该留下错误日志，以便排除故障时留下线索。 如何处理异常，这和你的系统设计方案有关 以三层架构（表现层、业务逻辑层、数据访问层）和前面说的数据库访问失败为例，在你的数据访问层提供了方法： getXXX(); getYYY(); updateXXX(XXX data); updateYYY(YYY data); …… 对异常的处理你可以 1、在你的数据访问层捕捉异常，如果是 getXXX 方法出现异常，返回null，如果是updateXXX 方法出现异常，返回false，在数据访问层记录事务日志，逻辑层根据数据访问层的返回值进行逻辑处理 2、在数据访问层声明抛出异常，由逻辑层进行统一捕捉，并记录错误日志。同样通过返回值，让表现层来决定提供哪些信息给用户 3、其它方式我不常用，当然系统设计也不会只有三层设计一种方式，就不说了 异常处理是一种策略，一旦确定，则应该进行统一规范，不能让各个程序员过于自由发挥 以前做过一个项目，有一个在移动、银联平台之间办理手机充值业务的模块。原本的逻辑简单点说，向银联请求扣费，如果成功，则向移动请求充值，结果写这个模块的老兄，只要是java要求捕捉异常的地方全部加上try...catch，然后继续往下走。结果就是出现大量的扣费不成功，充值成功（运营企业为客户白白充值，但收不到钱）；或者扣费成功，但充值不成功引来客户投诉。

我比较同意你的观点，在三层架构中，应该每一层都要捕获异常。 而不是一味的，从dao抛到service，再从service抛给controller处理。 每一层捕获到异常信息，处理完后，返回给上一层的，应该是自定义的可识别的异常信息，而不再是原始的exception，你觉得这样对吗？[/quote] 不好说对和错，不同的人设计出来的架构应该有他的理由和优缺点 我的几个项目里，DAO的异常都是抛给逻辑层处理的，因为我的DAO会设计得很简单，重要的是它是给很多个模块共享调用的。如果在dao层里处理异常，则逻辑层要作很多逻辑判断 比如一个事务会对数据库有五次访问，以下代码是DAO层声明抛出异常时的处理逻辑： try{ Dao1 dao1 = new Dao1(); dao1.method1(......); ...... Dao2 dao2 = new Dao2(); dao2.method2(); ...... dao2.method3(); ...... dao2.method4(); ...... }catch(SQLException e){ // 记录事务日志 // 回滚数据库事务 } 而如果在DAO层捕捉并记录日志，通过返回值为逻辑层提供数据库访问结果，则逻辑层代码会变得复杂： Dao1 dao1 = new Dao1(); if(dao1.method1(....) == false){ // 回滚数据库事务 return; } Dao2 dao2 = new Dao2(); if(dao2.method2() == false){ // 回滚数据库事务 return; } ...... 显然第二种方式代码量会多很多，所以我的项目里一般会用第一种方式 还有一点就是，DAO 层是被多个逻辑层共享调用的，如果在DAO层里捕捉异常并记录日志，则无法知道到底是怎样的业务逻辑引起异常，线索会丢掉很多，不利于查错。

[乐之者v]

个人理解。。 如果知道可能会出错的异常类型，就try catch,并做出相应的处理。。 如果无法预测。。直接throws..

[分享是一种美德]

异常处理最忌讳的就是catch后不处理，直接打印一句e.printStackTrace() 这样如果有问题就会隐藏掉， 内部的方法调用的时候可以往上抛异常 例如，dao层一个抛给service层，service层再抛给Controller层，Controller层就不要再抛了

[皓宝宝]

33333333333333333333333333333333333333333333333333333333333333333333

[ljheee]

引用 3 楼 u012259256 的回复:

[quote=引用 1 楼 kailiang_li 的回复:] 底层代码的话使用throw往上层抛，顶层代码直接try catch。

throws往上层抛，总也得有个限度吧？难道一直抛到最上层？[/quote] throws往上层抛，底层代码即使catch到，处理了异常，用户也无法得知，所以一般底层使用throw往上层抛，抛到用户界面层，也就是说当程序系统操作等 有异常的时候，毕竟在界面层，可以用界面化方式告诉用户有xx异常，比如弹出一个提示框，

[ok406lhq]

我也想知道啊

[一米阳光_sunny]

两者同时使用才是最好！

[hugh_z]

66666666666666666

[cattpon]

看看是什么~

[ggtxm]

智能H3输入法

[执笔记忆的空白]

引用 25 楼 zoeg 的回复:

每个模块都有自己的输入输出 你不要把try...catch...finally当做另类来看待,你应该把异常信息当做这个模块的输出来看待就对了! 大老板:"把A给我搞定!" 一把手:"A缺少a,干不了!" 大老板:"我不要听这个,你给我搞定!" 一把手:"把ABC给我搞定!" 小弟:"A缺少a,干不了!" 一把手:"我去把a弄来给你,然后你再试一次!" 小弟:"搞定了!"

这个比喻和恰当，其实抛与不抛，跟你的业务处理也有关系，比如 你需要在Service层捕获并处理，那么就在catch里面处理就行了 但是有时候，你需要吧这个异常告知某某调用者，让他去做异常处理，那么就throws抛出去

[qq_29933003]

底层代码的话使用throw往上层抛，顶层代码直接try catch。

[跟着蜗牛去看海]

最近正纠结这个，，，

[钠离子zi]

引用 40 楼 jliu200861 的回复:

其实这个取决于你要不要对exception进行处理，就比如你写的是通用的sdk或者方法给别人调用，而这时这些sdk里的方法不知道上层是否要根据具体的exception进行UI的展示或者其它操作，这是它就可以throws往上抛，直到有一处的代码要对具体的exception做出处理了，就用try catch处理，如果都不用做处理的话，其实就可以在任何地方进行try catch，只是为了图方便，就统一在最上层catch了，其实这大多还是习惯问题，没有说一定要在哪用throws在哪用try catch的吧

也不是简单的习惯问题，每个程序员的习惯都不一样，那这样的代码，就千差万别了，从一开始就不健壮的代码，以后维护也会老火的很，是吧。我个人还是倾向于团队内部，制定统一的规范，甚至能有一本像clean code这样的书籍，广而告之，统一规范

[jliu200861]

其实这个取决于你要不要对exception进行处理，就比如你写的是通用的sdk或者方法给别人调用，而这时这些sdk里的方法不知道上层是否要根据具体的exception进行UI的展示或者其它操作，这是它就可以throws往上抛，直到有一处的代码要对具体的exception做出处理了，就用try catch处理，如果都不用做处理的话，其实就可以在任何地方进行try catch，只是为了图方便，就统一在最上层catch了，其实这大多还是习惯问题，没有说一定要在哪用throws在哪用try catch的吧

[sinat_31790019]

虽然对try catch 和throws理解的并不深刻，但是看了大家的回帖，感觉几位大神的总结和观点还是很深刻的。关键要记住：对异常的处理，是能够明确不同异常类型，方便日后查错，还有要服务于业务逻辑，根据对业务逻辑的理解去在项目设计的时候统一对异常的处理规范，还有就是throws一定要尽量明确异常时单一的可查的，如果是try catch 一定要进行处理，或提示，或设置默认值，不能只做异常打印，同样不利于后期的代码维护。小白言论，姑妄听之。

[weixin_35722556]

个人理解，有不适之处，大家指正 异常 故名思意 就是不正常的情况，那么就可以用 类 Exception 来统一处理。 java 中Exception有什么特征呢 ？ 第一种 “可以预料到” 的Checked Exception， 一种“无法预料”到的 RuntimeException 所有预料到的Exception 必须处理（要么抛，要么catch），理由既然能预测为何不处理？ 无法预料RuntimeException 可以不处理，直接停止程序，提示用户，让程序回归正常环境。 那么涉及到第二个问题： 如何处理？ 那么我想问： 现实中我们 计划一个事情的时候，是不是有很多种异常情况，我们设置的备用方案，还有一些突发情况无法设置方案？ 1. 计划一件事情： 就是所谓的主逻辑。 2. 异常情况备用计划 就checkedException。 那么这些如何处理呢？ 我感觉涉及到产品方面的理念。 比如输入邮箱，那么是不是在页面展示上就提示用户输入合理的字符？ 有人就是乱输入，这块是不是前端逻辑处理掉？用if else 还是try catch 请高手回答。是主逻辑与 判断逻辑 交融，还是 主逻辑 与异常处理分开？ 3. 对于突发情况，没有备用方案（无法if else 或者十分繁琐） 直接try 记录日志，回滚等，并告知能处理的人 4. 补充： 自定异常，保持编码 统一。

[inclurc]

不明觉厉，过来学学交流