在页面有个label用来显示dal层的出错信息,这个出错信息来自dal层的try ...catch ex as exception中的ex.tostring,我该如何办?

解决方案 »

  1.   

    在catch块捕获异常,并将字符串赋予label.text属性.
      

  2.   

    具体如何实现?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 的赋值
      

  3.   

    Public   Property   ErrM   As   String 
                    Get 
                            if(strErr!=null)////////
                            Return   strErr 
                    End   Get 
                    ... 
      

  4.   

    谢谢楼上的,不过,现在的问题是,strErr 始终为空啊,那该如何解决?
      

  5.   

    1  设个断点,监视看看就知道问题是什么了, 下次请先调试后提问(比如可能你再次实例化了Sql类)2  如果真的是三层结构,压根就不应该在UI层显示DAL层的异常!!!各层各自做各自该做的事,UI层最多只应该显示他的下面一层,就是逻辑层的异常。 而且在界面层直接进行Insert操作这是哪门子3层结构哦。建议你不要跳跃性学习,一步一步走吧,你还没明白三层是什么。 
      

  6.   

    5楼上不知道做三层是怎么做的。有机会交流。我这里都是参照微软Enterprise Library的方式用结构化异常来处理一般是DAL抓取底层异常后要throw出来,例如DALClass {...public void DoSomething()
    {
    try {
    ...
    }catch (Exception ex)
    {
    throw new DalException("DoSomething fails", ex);
    }这样上面的BL和UI都可以看到一个很好的封装过的异常了。而且实际异常以Inner的形式存在,有必要的话上面的层也可以使用来做分析。
      

  7.   

    至于LZ的问题,如果采用我那样的架构,那么就在UI里面抓DalException,然后取InnerException的ToString()结果好了。
      

  8.   

    回复6楼: 微软Enterprise   Library ,并不是微软自己做的,而是OEM其他公司的东西,你可以看到这个东西里的代码风格明显不同于微软的系统类库的代码风格。而且这个东西只是其中一层而已,抛出异常没有问题,我说的问题是“捕捉的地方”,这跟EL没有关系。你这种说法是对的,但是跟我说的不冲突,你在DAL里抛出结构化的异常是可以的,但是这个异常不应该是UI层来处理,否则你的UI将与DAL出现高耦合,3层也就失去意义,仅仅是“为了三层而三层”, 请问你们都问过自己为什么要三层了么?你因为这个获得什么好处了?
    你的结构化的异常也只能是BL层来捕捉和处理,UI层只应该处理BL层的异常,“绝对不应该”直接设计成让UI直接处理DAL的东西。
      

  9.   

    回楼上的,使用严格三层很多时候会让人痛不欲生,呵呵。所以我经常会让BL和UI都能访问到DAL。这样虽然有耦合,但是在控制之下,不至于对项目产生太大影响。划分三层对我个人来说最大的好处是在测试方面,我可以Mock或者做成Stub的东西清晰多了,很容易做出方便的测试。我不是学术派,一切灵活为原则。因此像“绝对”之类的东西在我的项目设计里面不怎么经常出现。^-^
      

  10.   

    你的想法跟四年前的我一样,不过随着继续做更复杂的应用和更大的应用,这种想法让我吃了很多苦头~~~让UI直接访问DAL带来的好处极其微小, 至于你说的痛不欲生只是因为设计的问题而已,设计得好,就会优雅而且方便。 我也不是学术派也讨厌学术派,但是我是用18年多的代码经验不断试出我觉得应该做的和不应该做的事。在我写代码的前面13年间完全没有考虑过整体设计上的问题,因为做的东西太小了。 直到2002年的一天突然听说了3层这个新名词,以试试的想法实践了一些几千几万的小项目里面的设计,得出跟你一致的结论,所以我就偶尔会越过BL层,但是在其中一个项目里第一次吃到苦头,那是给电视台做的观众短信平台,由于需求的极大变化使得一些本来可以控制的东西变得混乱;不过我只认为是个意外,不认为是总体结构上的问题,第二次出问题是在做一个大系统,当时是打算跟中国电信的“家校通”平台争市场,但是结局很悲惨,输在自己手里,我开始分析问题,我当时又次错误地认为是因为“压根就不需要分成四层”因为我当时觉得是分层提升了开发成本超出预计致使项目进度滞后,所以跟很多朋友深入讨论了一个话题“为什么要分层,到底要不要,什么时候要,什么时候不要”,结论是要么不要分层,把类逻辑实现清楚就算了,要分就要分清楚了。而且也终于恍然大悟了一件事情,我原来几年里都在大说特说“分层”,但是我都是为了分层而分层,组成分层理由的原因都是非常肤浅的“看起来舒服”,“方便分工”,“逻辑清楚”~~~  真正是为了分层而分层,其实只要代码设计得好,不用分层照样也可以分工明了,也可以很舒服,逻辑也可以是清楚的,也可以很方便单元测试~~那又是为了什么而花费更多的开发成本来分层?
    在我由迷恋分层到抵触分层再到合理地分层的迷茫摸索中,我浪费了3年时间,到05年才醒悟,追悔之前很多系统都是我应该负全责的。 
    分层而不分清楚,不如不分,是我最大的收获,之后我在中国移动带领团队开发大中型系统的时候,我时刻谨记。 100万预算以上的系统都会分层,而我也试过60多万的系统不分层的,也有七八万的系统分出20多个项目的,一切指导思想只是这个项目的需求变动和后期维护的百分比预估,而时间也一次又一次地证明了这么做是正确的。不管是大型的需要分布式把一个程序掰开很多个部分,部署到一群机器上,还是小到只有一二万行代码的小程序都是如此。
    要么不分,要分就分清楚!   为了测试为了好看为了分工这些分层的借口都是自己骗自己而已,不过是披着分层的皮,代码还是耦合一起的,UI的错误依然会一下一下穿过很多个地方最终在数据库爆发~~ 数据库的本应该技术人员调试时看的信息也会不小心出现在完全不懂技术的客户面前 当系统复杂程度超过一定范围,量变就会成为质变,本来可控的耦合会让人欲哭无泪~~~ 
      

  11.   

    谢谢syeerzy、lextm和其他参与的,让我学到了好多说实话,我是刚开始自学三层结构,所以好多地方还不懂,程序也就不入眼了
      

  12.   

    如果一个对象的某个过程产生了Exception,调用者通过 try...catch 来捕获exception的信息。你设计为通过这个对象本身的某个string类型字段来由调用者获得exception信息是画蛇添足反而怪异的。如果你的所谓DAL层本身不能“消灭”exception,就不要去写try...catch。异常信息根本不可能从本没有异常的对象自身去获得。
      

  13.   

    如果你的SQL对象自身处理Exception,那么你就不应该再去考虑“DA.ins   出错,得到   ex ”这种。
    你的DA.ins根本不可能引发任何异常。反倒是你应该在使用 ErrM  的时候应该判断它的值是不是 Nothing。不过,这种“掩盖异常”的编程风格往往应该是一个程序员不重视程序员应有的责任的表现,应该做为一个技术问题,而不看暂时是否有效。
      

  14.   

    to sp1234:我想问的问题其实就是如何把在dal层进行数据库操作(插入、更新等)时,通过try...catch  捕获exception
    的出错信息,在网页页面显示出来,这样可以及时了解哪里出错了
      

  15.   

    这位兄弟,你的想法很不错~但是,你要考虑到,所谓的分层,就是尽量将DAL层与UI层分开!你现在又要将二者进行挂钩!这是一种错误的思路
    折中的办法如下:定义一个错误类,用来记录错误信息
    在DAL层某类出现问题时,将错误信息赋给该类的错误信息属性,然后在BLL层进行判断,再反馈到UI层!另外,我自己没有证实过,许多人建议尽量少用try Catch,理由是费资源!
    能预见的错误,用我说的方法返回错误信息,无法预见的,再用try catch
      

  16.   

    我来说一下我的做法吧,借用c/s开发里的一个func: getLastError我们在b/s里也可以写这个样的func,搞个globle的类, string static errormsg;
    不管在哪个层的问题都可以向这个error里写,
    在你需要判断时,查一下这个类就可以了
      

  17.   

    例:
    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层
    要灵活运用哦!