To lapwing2002():我又想了一下，我的三个异常分别处理，不可能有永远不执行的异常呀？这段异常处理确实有毛病，不过没有永远不可能执行的抛出异常，刚才我没考虑好，现在我想明白了，如果上面的出现异常并且rollback不出现异常，那么第二个异常抛出，如果rollback也出现异常，这个时候第二个异常将不会被抛出；
作为补偿，告诉我你的email，我发给你一个我整理的关于异常处理的文档
楼上我也要，呵呵。 [email protected]致命异常还是原样抛出最好，比如SQLException 过多的throw new CustomerException也是很消耗资源的现在我对new这个关键字很感冒了.
To 孙小美：代码整洁与功能性和可维护性比较，你觉得那个比较重要？虽然 ManFirst的方法也可以用，但是并不好，因为在捕捉例外的时候，不知道实际错误 在哪儿，不是很好，不便于调试、维护和理解。而对于lapwing2002所说的情况也 不存在。所以，我个人觉得我会仍然使用比较倾向于你所使用的这种方式
To javafounder(漂流) :我的方式有时会有错误不能抛出，比如rollback出现错误，那样的话，ex将不能被抛出；另外有些地方还不太合适，比如：我要删除多条记录，而中间一条出现错误（我所说的这种错误并不是真正的异常，而是其他表有关联或者其他的业务方面的限制），这样下面的删除将不能继续执行；而比较好的效果是把不能删除的提示给用户，而能删除的全部删除。请大家继续。
的机制和你最后抛是一样的。
比如：
error=true;
errorDES="错误描述！";
最后加上
if(error)
{
throw new CustomException(errorDES);
}
try {
con.rollback();//可能抛出SQL异常
}
catch (SQLException ex1) {
throw new CustomException(CustomException.DB_FETCH_DATA_ERROR,ex1.getMessage());
}
throw new CustomException(CustomException.DB_FETCH_DATA_ERROR,ex.getMessage());
} 像你这样先处理Exception 后处理SQLException ，存在一个严重的问题是后面处理SQLException 的部分永远不会被执行。编译器至少应该给你一个警告吧。 另外建议你在你的CustomException内部包含一个ArrayList（或者其它容器成员），用来包含引起这个异常的其它异常（例如SQLException），不要用你自己的CustomException完全掩盖了其它的异常
boolean ifError=false;
String ErrorInfo="";
try {
con.setAutoCommit(false);//可能抛出SQL异常
CurriculaTestQuesDAO quesDAO = new CurriculaTestQuesDAO(con);
CurriculaTestDAO testDAO = new CurriculaTestDAO(con); if (testDAO.selectByFK(ques.getCurriculaId()).getId() == 0) {
CurriculaTest test = new CurriculaTest();
test.setCurriculaId(ques.getCurriculaId());
test.setIsActived(false);
testDAO.insert(test);//可能抛出CustomException
}
quesDAO.insert(ques);//可能抛出CustomException testDAO.updateCount(CurriculaManageBO.ADD_QUES, ques.getCurriculaId());//可能抛出CustomException
con.commit();//可能抛出SQL异常
}
catch (Exception ex) {
try {
con.rollback();//可能抛出SQL异常
ifError=true;
ErrorInfo=ex.getMessage()+"\n";
}
catch (SQLException ex1) {
ifError=true;
ErrorInfo=ErrorInfo+ex1.getMessage()+"\n";
}
}
finally{
try {
con.setAutoCommit(true);//可能抛出SQL异常
}
catch (SQLException ex2) {
ifError=true;
ErrorInfo=ErrorInfo+ex2.getMessage()+"\n";
}
this.closeConnection(con);
if (ifError)
{
throw new CustomException(CustomException.DB_FETCH_DATA_ERROR,ErrorInfo);
}
}
}
testDAO.insert(test);//可能抛出CustomException
如果抛了
quesDAO.insert(ques);//可能抛出CustomException
是不会被执行的。
你要明白代码的简洁来自于逻辑的清晰。
[email protected]致命异常还是原样抛出最好，比如SQLException
过多的throw new CustomerException也是很消耗资源的现在我对new这个关键字很感冒了.
ManFirst的方法也可以用，但是并不好，因为在捕捉例外的时候，不知道实际错误
在哪儿，不是很好，不便于调试、维护和理解。而对于lapwing2002所说的情况也
不存在。所以，我个人觉得我会仍然使用比较倾向于你所使用的这种方式
所要实现的逻辑思想
就好比说，如果并发只有1、2条每秒，你有必要每个变量都优化吗。
我决定简洁的话，以后改代码就更方便。
但是，如果是并发50条每秒，那么TRY CATCH的方法是不可取。
因为程序效率低，代码有没有规划，要是你看代码满眼的TRY CATCH 你受得了吗？
比如：我只是想删除一条记录，而这条记录有关联，不能删除，这样的话，如果通过标识，然后最后抛出，就不可以了，如果那样会造成记录已经删除。
----
这是不存在的既然是一次COMMIT的话那就是个事务怎么会有这种情况呢。
{
throw new CustomException(CustomException.DB_FETCH_DATA_ERROR,ErrorInfo);
}
我也抛了只是不用 try
catch
所有代码而已。
比如：我只是想删除一条记录，而这条记录有关联，不能删除，这样的话，如果通过标识，然后最后抛出，就不可以了，如果那样会造成记录已经删除。
----
这是不存在的既然是一次COMMIT的话那就是个事务怎么会有这种情况呢。
----
你的异常是在commit以后才抛出的。
boolean ifError = false;
try{
con.setAutoCommit(false);
if (有关联){
ifError = true;
}
else{
删除操作;
}
con.commit();
}
catch(SQLException e){
}
finally{
}
你甚至可以
if (ifError){
con.commit();
}
else{
con.rollback();
}
public CustomException(int errCode, String errMessage,Exception ex) {
super(errMessage);
this.errCode = errCode;
this.sysErrMessage = ex.getMessage();
}
这是我的一个理想化的一个构造方法，第一个参数是错误号，第二个参数是我们自己写的消息提示，是给用户看的；第三个就是上层抛出的异常，一般都是没有经过我的CustomException构造的异常，我把这个异常信息也放到我的类里面，留着以后写到错误日志里，在程序员查看日志的时候可以知道究竟是什么产生了异常！(实事上我把异常保存在 CustomException的一个ArrayList里面)
这个是比较理想的，有一个问题，如果ex是我上面已经经过CustomException构造的异常的话，那么我该如何处理呢？
判断
ex instanceof CustomException
判断
这两句我都不大明白。能具体一些吗？