|
锁定老帖子 主题：JAVA异常设计原则
精华帖 (7) :: 良好帖 (6) :: 新手帖 (0) :: 隐藏帖 (1)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2011-01-05
最后修改：2011-01-05
luckaway 写道 gdpglc 写道 dao 可以不抛checked exception. 但是，出现下面的情况，是不是需要在service里边处理异常呢？ 比如某个Service方法写成这样了呢： 1. file logic 2. dao invoking logic 不是很明白你的意思，file logic不应该直接在Service处理，操作File都应该放在Dao里处理 为什么呀？ 那操作email、jms等等呢，也都放到Dao里吗？ 你在Dao处理文件IO异常的方式，好象是说，如果有IO问题，就算程序Bug是这个意思吗？因为你抛的是一个unchecked exception. 我没用过Spring，不好意思，可能问的很初级。 |
| 返回顶楼 | |
|
发表时间：2011-01-05
luckaway 写道 yanical 写道 luckaway 写道 2. 转账的额度是页面单选框(100、200、300、400、500)选择的： 转账的额度用户不能轻易的更改，但是不排除有些无聊的人会借助其他工具（如，firebug）来修改。此类事件还是占少数的，我们就可以把它归结为非软件bug的异常事件—业务异常（Checked Exception）。 正确的实现如下 不错。不过比较疑惑的还是什么时候用Checked Exception，什么时候用Un-Checked Exception。 一直赞同的一个观点是：只有在客户端可以通过某些手段来弥补发生的错误时才使用Checked Exception。 似乎楼主也支持这个观点？但是我一直没有发现过那个地方可以确定客户端可以弥补错误，包括楼主举的上面这个例子，我觉得这个时候客户端也没法做什么了。而且为了这种小可能做成Checked Exception，让调用的地方都要来处理，好像把代码搞混乱了。 改成Unchecked Exception我们只能提示用户“系统错误”之类的，感觉就是软件bug了。 我个人觉得这种事件，还是可以容忍的，应该给用户一个明确的提示，告诉它不要修改radio值 就个例来说，首先这种情况不应该抛出异常，不管什么异常。而是要提供数据验证功能。服务端不该依赖客户端来保证数据完整性吧? 如果换个客户端实现不完了。 异常是不是就只该用在没法预料的情况呢？ 我觉得可以斟酌一下，像这个例子肯定是可以预料的情况，就应该是验证的功能。 到目前为止我觉得有必要用Checked Exception的地方也只有IO的时候的异常 |
| 返回顶楼 | |
|
发表时间：2011-01-05
yanical 写道 就个例来说，首先这种情况不应该抛出异常，不管什么异常。而是要提供数据验证功能。服务端不该依赖客户端来保证数据完整性吧? 如果换个客户端实现不完了。 异常是不是就只该用在没法预料的情况呢？ 我觉得可以斟酌一下，像这个例子肯定是可以预料的情况，就应该是验证的功能。 到目前为止我觉得有必要用Checked Exception的地方也只有IO的时候的异常 言之有理，这个是应该属于简单的数据验证功能，不应该有异常来控制，这个例子是不是合适，误导大家了！ 我等会来改下 |
| 返回顶楼 | |
|
发表时间：2011-01-05
最后修改：2011-01-06
gdpglc 写道 luckaway 写道 gdpglc 写道 dao 可以不抛checked exception. 但是，出现下面的情况，是不是需要在service里边处理异常呢？ 比如某个Service方法写成这样了呢： 1. file logic 2. dao invoking logic 不是很明白你的意思，file logic不应该直接在Service处理，操作File都应该放在Dao里处理 为什么呀？ 那操作email、jms等等呢，也都放到Dao里吗？ 你在Dao处理文件IO异常的方式，好象是说，如果有IO问题，就算程序Bug是这个意思吗？因为你抛的是一个unchecked exception. 我没用过Spring，不好意思，可能问的很初级。 如果email抛出的是业务异常，用户是能为此做纠正的，比如邮件地址不存在，那就要继续往上抛，若觉之前的业务异常不过明确或者提供的信息不够，比如邮件地址不存在，但是它并未提供那个邮件地址不存在，你也可以封装成另外一个带邮件地址的明确的业务异常。 如果是用户是无能为力的，比如IOException，那就转换成RuntimeException。直接在Service里做转换也是可以的 |
| 返回顶楼 | |
|
发表时间：2011-01-06
最后修改：2011-01-06
try{
//code...
if(不满足某条件)
throw new XXExcption("请填写必要的值");
//other code...
if(不满足某条件)
throw new XXException("你操作的是非法的");
//other code...
//执行成功，跳转到成功页面或者是通过json返回ajax的请求。
}catch(Exception e){
//出错了，那就跳转到错误页面或者通过json封装错误（e.getMessage）返回ajax请求。
}
后来直接就抛出RuntimeException或者自己实现的继承RuntimeException的异常类，然后不管是通过Filter还是Struts2的Interceptor去统一截获异常并处理。
看了很多关于异常的文章，现在依然迷糊。 |
| 返回顶楼 | |
|
发表时间：2011-01-06
最后修改：2011-01-06
引用 以前有部分项目是这么处理的，在Action里面。那时候项目并没有分层，直接在Action里调用封装好了hibernate的CURD方法。开发很快速，但是代码也比较乱。
try{
//code...
if(不满足某条件)
throw new XXExcption("请填写必要的值");
//other code...
if(不满足某条件)
throw new XXException("你操作的是非法的");
//other code...
//执行成功，跳转到成功页面或者是通过json返回ajax的请求。
}catch(Exception e){
//出错了，那就跳转到错误页面或者通过json封装错误（e.getMessage）返回ajax请求。
}
后来直接就抛出RuntimeException或者自己实现的继承RuntimeException的异常类，然后不管是通过Filter还是Struts2的Interceptor去统一截获异常并处理。 看了很多关于异常的文章，现在依然迷糊。 Action不应该再抛异常了 try{
//code...
if(不满足某条件){
context.put("errorMessage","请填写必要的值");
return INPUT;
}
//other code...
if(不满足某条件){
context.put("errorMessage","你操作的是非法的");
return INPUT;
}
//other code...
//执行成功，跳转到成功页面或者是通过json返回ajax的请求。
}catch(RuntimeException e){
context.put("errorMessage","服务器出现错误，请联系管理员");
return ERROR;
}
}catch(RuntimeException e){ context.put("errorMessage","服务器出现错误，请联系管理员"); return ERROR; } 或者 }catch(Exception e){ context.put("errorMessage","服务器出现错误，请联系管理员"); return ERROR; } 不一定在每个Action里都处理，可以统一处理。 |
| 返回顶楼 | |
|
发表时间：2011-03-31
我个人觉得，checked exception 更多的是用来控制流程，至于楼主说的“正确的流程”，没有明确的定义，也很难定义
|
| 返回顶楼 | |
