三层开发错误在哪层捕捉?

Question

用三层开发，DBAccess(数据访问层),Bil(逻辑层),WebUI(界面层)
在界面层里调用 BIl.InsertOrder
Bil层里又调用  DBAccess.execute(',',')更新到数据库那么如果出现错误一定是在 DBAccess.execute(',',')出现错误
这时要在哪一层捕捉进行错误处理，并显示给用户看。
请大家说说都是怎么处理的！

Answer 1

逐层catch，可以返回到页面上

Answer 2

最底层catch
然后返回个值
其他的层只要这个值就可以拉
层层catch乱费资源

Answer 3

数据访问层捕获的异常 -〉逻辑层 -〉界面层1、数据访问层捕获的异常：
    可以写log文件，然后抛出一个自定义的异常到逻辑层。2、逻辑层：
    可以写log文件，做错误解析，给界面层一个返回值。
    
3、界面层：
    应该根据逻辑层的返回值等作错误处理，比如提示框等告知用户。

Answer 4

我认为不能在数据访问层捕获并处理，sqlhelper里好象都没有捕获错误。
继续关注!
smin1994(smin1994)的逐层catch，可以返回到页面上要怎么做。

Answer 5

做一个公共的捕获异常页面，把异常都throw这个页面里边去。再显示给用户看

Answer 6

swordragon(古道热肠) 的方法不错。
 有没有例子参考一下。

Answer 7

我觉得所有层都要，因为每一层都有可能发生异常，都写入写log文件就行了，给用户看都没有什么用，用户看得明白吗？

Answer 8

同意 pwqzc(吴旗娃徒也~~老鼠粮仓之路) 异常不做当然要在最底层了 ，比如 DBAccess(数据访问层) 。然后可以有几种处理方式：1.记录到日志2.用 System.Web.HttpContext.Current.Response.Write("错误信息");直接输出。3.设置一个属性，比如ErroeMsg ,执行一个方法后，判断这个属性就行了，而不用catch。因为catch太慢，而且浪费资源。
以上这几种各有优缺点。最不应该用的就是层层catch吧。很浪费的，代码也会长不少。

Answer 9

尽量考虑更多可能的异常，详细的异常的代码写入log文件，然后在ui给用户一个尽量简单易懂的出错提示，并能够提供用户自己解决的方法，毕竟不能把用户当成专业人员，而且我们面对的用户大多数都属于急功近利的那种，如果仅仅给一个出错提示 那么用户对软件的印象可能会大打折扣。

Answer 10

自己定义一个异常类，在DBAccess层捕获错误。

Answer 11

public class DBException:Exception
{。。}
public class DBAccess
{
public void OpenConnection()
{
try
{
DBConnection.Open();
}
catch(Exception e)
{
DBException dbe=DBException.GetDBException(ErrCode.ExecuteNonQuery,e);
throw(dbe);
}
}
}

Answer 12

public class DBException:Exception
{
      .
      .
      .
      .
public static string GetDBErrMsg(ErrCode DBErrCode)
{
string ErrMsg="";
switch(DBErrCode)
{
case (ErrCode.OpenCn):
{
ErrMsg= "打开数据库连接错误！——";
break;
}
case (ErrCode.ExecuteReader):
{
ErrMsg= "读数据库错误！——";
break;
}
case (ErrCode.ExecuteNonQuery):
{
ErrMsg= "执行数据库命令错误！——";
break;
}
case (ErrCode.BeginTransaction):
{
ErrMsg= "开始数据库事务处理错误！——";
break;
}
}
return ErrMsg;
}
}

Answer 13

............
建议在不是文档很正规的情况下，不要使用自定义异常，否则，人员一旦变动，或者即使是自己，过了一段时间，都不知道自定义的是什么了。而使用原始异常就没这个问题－－一家之言
----------------------------------------------------------------------------------
RE：catchdream(星剑)
你知道异常类是写在什么地方的吗？人员变动和自定义异常有什么关系？你意思是，换了个人，不用自定义异常类，就不用熟悉以前的代码了？对于自己写的异常类，自己都看不懂，那只能说这个类是你盗窃的！还有一点！！自定义异常类，和文档规范不规范是没有关系的！异常类是写在类模板的数据访问层里面的（至少我是这样）。你知道什么叫分层吧？？

Answer 14

to liuxiang027(Nail.柳翔)
sigh ,你无非是捕捉系统抛出的异常，另外抛出自己的异常吧，我问你，你确定在这个系统中只有你定义了异常类？要是没个人都定义一个，那你自己去看代码吧，另外，你作的每个系统定义的异常类是相同的么？要是这样，那么恭喜你了，否则，挑战自己的记忆力吧，我是觉得我没有这么好的记忆力的。

Answer 15

RE： catchdream(星剑)
  数据访问层的代码，你们公司是一个系统一个访问层吗？那你们还要访问层做什么啊？每个公司为什么要定义自己的一套类模板？一个类模板里面会有多个异常类吗？？对！我们公司的异常类，就是我定义，因为类模板就是我来写，别人直接用。
case (ErrCode.OpenCn):
{
ErrMsg= "打开数据库连接错误！——";
break;
}
case (ErrCode.ExecuteReader):
{
ErrMsg= "读数据库错误！——";
break;
}
case (ErrCode.ExecuteNonQuery):
{
ErrMsg= "执行数据库命令错误！——";
break;
}
case (ErrCode.BeginTransaction):
{
ErrMsg= "开始数据库事务处理错误！——";
break;
}
你认为这几个CASE不是所用访问数据通用的？请问一下！在什么系统下不能用这几个CASE。当然，在用的过程中，发现有不足的！随时加CASE！对于扩展性，也是没有问题的！
请继续提出你的高见！

Answer 16

异常是向上层堆栈递归的总的来说在UI层是一定会捕获的如果想知道在哪里抛出的 Exception 已经提供了那样的功能同时在一个地方统一处理也便于管理

Answer 17

zyug(LovlyPuppy)我很赞成你的意见。
-----------------------------------------------------------------
异常是向上层堆栈递归的
总的来说在UI层是一定会捕获的
如果想知道在哪里抛出的 Exception 已经提供了那样的功能
同时在一个地方统一处理也便于管理
-----------------------------------------------------------------我的思想也和你一样。所以我在访问层里面，对每个对象内部进行异常的捕获。
例（如上方法）：OpenConnection()这个方法，做为对象来用，出现异常就可将该对象的异常抛出来显示！并不需要一层一层的捕获。
（欢迎不同意见提出，共同讨论）

Answer 18

回复人： liuxiang027(Nail.柳翔) ( ) 信誉：100  2005-09-15 10:23:00  得分: 0  
 
 
   public class DBException:Exception
{。。}
public class DBAccess
{
public void OpenConnection()
{
try
{
DBConnection.Open();
}
catch(Exception e)
{
DBException dbe=DBException.GetDBException(ErrCode.ExecuteNonQuery,e);
throw(dbe);
}
}
}
  
 

Answer 19

to liuxiang027(Nail.柳翔)
高见不敢，我开始就说处了一个前提，是文档齐全，我问你，没有文档，别人用的异常类时，是自己翻到你的代码来看你自己怎么定义的？而且要真定义异常类，系统中不可能只有数据库连接的异常类吧，那些可不是相同的吧

Answer 20

RE：catchdream(星剑)
  我都说了，是捕获数据访问的异常，这里讨论的也是数据访问的异常。你的意思也就是说，没有自定义异常类的话，类模板就不需要文档？就不用告诉别人怎么用里面的对象？既然需要，既然有的话！！那教人用类模板中的异常类，就是必然的！既然是必然的，为何一定要停留在牛角尖上？教人用的方式，也不一定要用文档的形式，配合默契的开发小组（技术水平平均），可以把使用类模板文档的时间给节约下来。
  所以，也不一定是非要文档齐全，才能自己自定义异常类的，首先请你搞清楚，异常类的好处在什么地方？如果按CMM标准做开发，光写齐全的文档都写死你，你也不用做开发了，可以当文员了。

Answer 21

case (ErrCode.OpenCn):
{
ErrMsg= "打开数据库连接错误！——";
break;
}
case (ErrCode.ExecuteReader):
{
ErrMsg= "读数据库错误！——";
break;
}
case (ErrCode.ExecuteNonQuery):
{
ErrMsg= "执行数据库命令错误！——";
break;
}
case (ErrCode.BeginTransaction):
{
ErrMsg= "开始数据库事务处理错误！——";
break;
}
从以上几个CASE中都能看出，捕获的异常有数据库的连接、读取数据、执行SQL命令及事物的处理。
你认为这些抛出的异常不全吗？那你可以提出来。

Answer 22

web方式的处理不多，我做的比较多的是cs的程序，处理方式一般是每层都做错误捕捉，捕捉错误后在错误中加入当前出错位置信息，比如当前函数的名称、类名称等，然后加上错误的代码、描述后再把错误抛出去，这样做的好处是出了错误很容易定位错误是哪里报出来的，解决问题很方便，千万不要catch了错误就不处理了，这样做以后程序就没法维护了，客户端报一个错误，可能要把所有的代码翻过来才能找到哪里出了问题。

Answer 23

对了，忘了说了，如果在最外层，为了界面友好，可以对错误的description进行一下处理，也就是 liuxiang027(Nail.柳翔) 所说的那样，这样可能对用户更友好写。但是千万要把出错的位置信息也一并显示出来（或者放到自己可以找到的地方），方便程序调试、修改

Answer 24

WEB 和 WIN其实也是一样的。分层处理数据的好处就是，哪层有错，就修改哪层。访问层传出的如果只是封装了数据访问的对象。只用对这个对象的内部做异常的捕获。UI层出的错，只用修改UI层，UI层基本上都不是操作数据的访问的了，操作的全部都是对象。逻辑层出错，只用修改逻辑处理层。每层负责各自的活动，层次分明的时候，程序报错一看就知道是哪一层有问题。

Answer 25

回复人： catchdream(星剑) ( ) 信誉：100  2005-09-15 10:59:00  得分: 0  
我常用的是：在底层只写一下日志。然后在显示层捕捉所有异常（一般而言，不能显示调试中那个出错的黄页给用户看，否则用户不知所措了。）对典型异常，转换成用户可以理解的方式（比如数据库数据重复，通过查找异常中的关键字即可知道）。其他错误进行屏蔽。
建议在不是文档很正规的情况下，不要使用自定义异常，否则，人员一旦变动，或者即使是自己，过了一段时间，都不知道自定义的是什么了。而使用原始异常就没这个问题－－一家之言
-------------------------------------------------------------------------------------
这些就是你本想说的是数据库操作以外的异常？
值得深思。

Answer 26

SORRY！上面语气或许有点激动了。今天的压力有点大，所以不知觉中语气重了点，请谅解！

Answer 27

sigh.
可是对于我说的这3种情况：关键字和现有冲突，操作表锁定，关联表被锁定。要求不同的处理方式呢？比如：关键字和现有冲突，我要求清楚给用户提示信息，让他修改关键自，而其他两种情况则屏蔽掉（只写日志以便复查用），怎么用你的Exception来实现呢，是不是扩充？那我再有其他情况，再扩充？

Answer 28

恩，对。只要能扩充的，就继续扩充这个异常类。
-----------------------------------------------------------------------------------
回复人： zyug(LovlyPuppy) ( ) 信誉：100  2005-09-15 11:20:00  得分: 0  
 
 
   异常是向上层堆栈递归的总的来说在UI层是一定会捕获的如果想知道在哪里抛出的 Exception 已经提供了那样的功能同时在一个地方统一处理也便于管理
  
-----------------------------------------------------------------------------------
这位朋友已经说的很清楚了，我也很赞成他的意见，如果你有不同的意见，也可以提出！

Answer 29

谢谢大家参与，看来我这个问题提的很有意义！
我准备用liuxiang027(Nail.柳翔) 的方法来捕捉数据访问层的错误,然后在表示层有选择的显示。
大家有好的方法多说说啊，三人行必有我师焉嘛