分层架构里，数据层有必要try-catch吗？
0
悬赏园豆：20
[已解决问题]
解决于 2009-09-16 12:57
如：
public static int XXX(string name)
{
try
{
i = Convert.ToInt32(
SqlHelper.ExecuteScalar(SqlHelper.ConnectionString, System.Data.CommandType.StoredProcedure, "xxx", new SqlParameter("@name", name))
);
}
catch (Exception ex)
{
throw ex;
}
return i;
}
还是在业务层去捕获?
最佳答案
0
当然有.捕捉异常并不是只能用在发生操作异常的时候，你完全可以自己定义异常来让try catch 捕捉。并再次throw，让应用层去捕捉。
最够所有捕捉的异常都要在web应用层用友好的形式体现，便于测试人员确定问题，或客户体验不会觉得你的程序bug很多。
收获园豆：10
其他回答(2)
0
放在业务层比较妥当。但是如果是团队开发，一定要协调好，否则都没catch,就把直接错误丢给用户了。如果放在数据层，调试起来是很累人的。
收获园豆：5
0
感觉无论那个层都需要Try catch, 如果是界面层catch则是把异常显示出来,
底层的catch一般用来做异常记录,一个系统,不可能没有问题,问题出现你怎记录呢..这就需要在底层的catch记录,然后throw到上一层
收获园豆：5
楼上的胡说八道！你这样的做法估计你的系统性能给超级差！
@Vincent Yang:
我不明你的怎樣做?难道你不需要try catch? 全部作答都是throw到上一层..我只按自己的愿意,记录异常,方便维护...不明白你这种高人怎做..怎样才会高性能呢?难道你连OO都不要,直接流水式写程序?
@Vincent Yang:
可能你以为在catch里以为添加的异常记录就会影响性能的话,你就大错特错...按你的想法,程序跑10000次可能会走9999次catch,那就会影响性能?但我告诉你..你的程序本身就有问题,这么多异常,还是程序吗? catch的机率在正确正常的程序下,一天运行,一个网站一天流量访问量是5000的,也就是记录了500条异常左右,我做的项目里面..
你的说法应该是我面试的人差不多.我问他怎记录异常,他说只在用户界面层显示错误就可以了..我当时就晕了,我引导式问他,如果程序里面出现BUG你怎跟踪? 他说用户提出问题我再去跟踪,我又问,那你们维护工程师是干什么工作的呢?他就说了一些系统机器的运作,数据的维护这些..我后来问他,如果在层底throw出来的异常,源头不需要记录异常吗?他回答这样影响性能..应该和你的回答差不多了..我当时就晕了..如果catch里面记录一个异常会影响性能的话,那你这程序先当否定..异常多到记录都影响了..那还需要这程序干什么呀? 他就没回答了.相信你的想法也是这种吧..在书上看到catch中处理过程是需要好大成本的..劝你以后做大项目时最好不定期是记录一下好,不然你程序运行后,你发现不了BUG..特别是大项目,几百个类,几万个方法,你怎查呀? 你记录到txt记录文件时做一个方法: 至少定义二个子参数,一个是位置,例如:UserInfo类下面有Add,Delete等方法,那个方法出现异常就记录UserInfo:Add,另一个参数是异常原因.最好把时间也记上来..
@风浪: 说的不错，我有个问题想请教你！
因为我做的后台，使用的是WCF服务，但是也分很多层，有Business，DAL层，那我的的try catch应该加在哪边，catch里面我是做日志记录的！
是加到WCF方法中吗？
