具体如何实现?label.text = ErrMa.SER = SQL.Ins("b")DA.ins 出错,得到 ex我的代码如下:sql.vbPublic Class SQL Private strErr As String Function Ins ... Try Catch ex As Exception strErr = ex.ToString ... Public Property ErrM As String Get Return strErr End Get ...a.vb Public Class a Function SER ... SER = SQL.Ins这样ErrM 始终为空,就是不接受 strErr = ex.ToString 的赋值
Public Property ErrM As String Get if(strErr!=null)//////// Return strErr End Get ...
Private strErr As String
Function Ins
...
Try
Catch ex As Exception
strErr = ex.ToString
... Public Property ErrM As String
Get
Return strErr
End Get
...a.vb
Public Class a
Function SER
...
SER = SQL.Ins这样ErrM 始终为空,就是不接受 strErr = ex.ToString 的赋值
Get
if(strErr!=null)////////
Return strErr
End Get
...
{
try {
...
}catch (Exception ex)
{
throw new DalException("DoSomething fails", ex);
}这样上面的BL和UI都可以看到一个很好的封装过的异常了。而且实际异常以Inner的形式存在,有必要的话上面的层也可以使用来做分析。
你的结构化的异常也只能是BL层来捕捉和处理,UI层只应该处理BL层的异常,“绝对不应该”直接设计成让UI直接处理DAL的东西。
在我由迷恋分层到抵触分层再到合理地分层的迷茫摸索中,我浪费了3年时间,到05年才醒悟,追悔之前很多系统都是我应该负全责的。
分层而不分清楚,不如不分,是我最大的收获,之后我在中国移动带领团队开发大中型系统的时候,我时刻谨记。 100万预算以上的系统都会分层,而我也试过60多万的系统不分层的,也有七八万的系统分出20多个项目的,一切指导思想只是这个项目的需求变动和后期维护的百分比预估,而时间也一次又一次地证明了这么做是正确的。不管是大型的需要分布式把一个程序掰开很多个部分,部署到一群机器上,还是小到只有一二万行代码的小程序都是如此。
要么不分,要分就分清楚! 为了测试为了好看为了分工这些分层的借口都是自己骗自己而已,不过是披着分层的皮,代码还是耦合一起的,UI的错误依然会一下一下穿过很多个地方最终在数据库爆发~~ 数据库的本应该技术人员调试时看的信息也会不小心出现在完全不懂技术的客户面前 当系统复杂程度超过一定范围,量变就会成为质变,本来可控的耦合会让人欲哭无泪~~~
你的DA.ins根本不可能引发任何异常。反倒是你应该在使用 ErrM 的时候应该判断它的值是不是 Nothing。不过,这种“掩盖异常”的编程风格往往应该是一个程序员不重视程序员应有的责任的表现,应该做为一个技术问题,而不看暂时是否有效。
的出错信息,在网页页面显示出来,这样可以及时了解哪里出错了
折中的办法如下:定义一个错误类,用来记录错误信息
在DAL层某类出现问题时,将错误信息赋给该类的错误信息属性,然后在BLL层进行判断,再反馈到UI层!另外,我自己没有证实过,许多人建议尽量少用try Catch,理由是费资源!
能预见的错误,用我说的方法返回错误信息,无法预见的,再用try catch
不管在哪个层的问题都可以向这个error里写,
在你需要判断时,查一下这个类就可以了
public void insert(string title,out string msg)
{
try
{
//数据库相关操作
msg="OK";
}
catch(Exception ex)
{
msg=ex.Message;
}
}前台调用:
string msg;
insert("aaa",out msg);
response.write(msg);这样就得到操作数据库时报的错!
可以将报错的操作放到BLL层
要灵活运用哦!