【机房重构】【报表】异常处理
2016-05-02 11:37
686 查看
不知道大家对{“本地报表处理期间出错”}熟不熟悉,反正我前几天一直头大得很!
{“本地报表处理期间出错”}这句话,一直萦绕我脑海,四五天的时间都没有解决了,一直被搁置,最后无奈,其他错误都能解决了,它还是没有处理掉,昨天晚上还在怀疑到底能不能解决,如果再解决不了这个问题,就让它解决了我算了,我也是醉了。
所幸,今天这个问题被我“攻克”了,在说这个问题之前,让大家看看我的报表及代码吧,以日结报表为例:
大家能看出哪里错误来吗?如果是此刻的我,肯定能一眼就看得出来啦,只不过我也是面向免了好几天才发现的哦,相信大家肯定比我聪明的多,看出问题所在是非常轻松的。好了,闲话先说到这里。只要我提一点,大家就知道哪里错了。
不知道有没有人比较过ReportParameter与Sqlparameter。
先来了解Sqlparameter,这个我是先熟悉的要了解Sqlparameter,就先理解下什么局部变量吧。局部变量(Localvariables)指在程序中只在特定过程或函数中可以访问的变量,而在SQL中,局部变量可以作为数据的传递者,通过局部变量,增删改查数据库特定表中的数据,相信大家对这个了解还是足够的。而SQL也强制要求必须使用局部变量,而SQL的局部变量命名为“@+变量名”。
到这里,是不是大家都看出来哪里的问题了?
ReportParameter是定义与报表中定义的参数同样的名称,从而进行数据传递。看到熟悉的后缀Parameter,我“理所当然”的定义了局部变量,然后,然后就错了啊,哈哈……
ReportParameter与Sqlparameter他们都可以传递数据,但是一个用在报表上,一个用在SQL语言中。
然后将“@”去掉,也就可以加载了。
在这里,我想要补充一点,在我们编码的过程中,最好不要上来就用Try……Catch ……语句。就比如这次报表的问题,系统就一直提示你“{“报表处理期间出错”}”,这样你能看出来什么问题?处理期间出错,我哪里知道期间什么地方错了,这几天真的对它非常无语,甚至都有拿电脑泄愤的念头了,结果电脑也害怕了,让我今天意识到这个错误位置了,哈哈。
好了,回归正题,如果我们编译期间出错,系统会异常,而异常会跟着很大的信息量表示错误原因,就像同下图一样。
不是不让用Try……Catch ……,它可以避免异常,不至于系统直接崩溃,但是,我个人觉得这个应该是程序编译完成之后,哪里可能存在异常就放在哪里,而不是什么地方都用它,对,是它能提示异常,能保证系统在异常以后不崩溃,但是,我们在编译的过程中是为了轻松?还是为了什么?相信大家在机房重构的时候D层出的错误肯定不在少数,然后系统提示的什么(在加了Try……Catch
……之后),是“数据库转换到Integer类型失败”,这是什么玩意?你懂?反正我不懂!是,敲的多了我们就知道是什么哪里出错了,可是我们最多知道在什么范围,你知道确切的错误信息?别逗我,经过大家用了Try……Catch …我可找不到确切错误位置。
Try……Catch ……也是为了防止出现的错误解决不了的方法,故而还是有些好处的。还是那句话,这不是在编译过程中该考虑的,而应该在调错阶段才加入的,那时候才会有更深的意思,否则加早了只会阻碍我们发现错误,这对我们以后一定会产生恶劣影响的!
以上建议仅供参考,随个人喜好就好!
{“本地报表处理期间出错”}这句话,一直萦绕我脑海,四五天的时间都没有解决了,一直被搁置,最后无奈,其他错误都能解决了,它还是没有处理掉,昨天晚上还在怀疑到底能不能解决,如果再解决不了这个问题,就让它解决了我算了,我也是醉了。
所幸,今天这个问题被我“攻克”了,在说这个问题之前,让大家看看我的报表及代码吧,以日结报表为例:
大家能看出哪里错误来吗?如果是此刻的我,肯定能一眼就看得出来啦,只不过我也是面向免了好几天才发现的哦,相信大家肯定比我聪明的多,看出问题所在是非常轻松的。好了,闲话先说到这里。只要我提一点,大家就知道哪里错了。
不知道有没有人比较过ReportParameter与Sqlparameter。
先来了解Sqlparameter,这个我是先熟悉的要了解Sqlparameter,就先理解下什么局部变量吧。局部变量(Localvariables)指在程序中只在特定过程或函数中可以访问的变量,而在SQL中,局部变量可以作为数据的传递者,通过局部变量,增删改查数据库特定表中的数据,相信大家对这个了解还是足够的。而SQL也强制要求必须使用局部变量,而SQL的局部变量命名为“@+变量名”。
到这里,是不是大家都看出来哪里的问题了?
ReportParameter是定义与报表中定义的参数同样的名称,从而进行数据传递。看到熟悉的后缀Parameter,我“理所当然”的定义了局部变量,然后,然后就错了啊,哈哈……
ReportParameter与Sqlparameter他们都可以传递数据,但是一个用在报表上,一个用在SQL语言中。
然后将“@”去掉,也就可以加载了。
在这里,我想要补充一点,在我们编码的过程中,最好不要上来就用Try……Catch ……语句。就比如这次报表的问题,系统就一直提示你“{“报表处理期间出错”}”,这样你能看出来什么问题?处理期间出错,我哪里知道期间什么地方错了,这几天真的对它非常无语,甚至都有拿电脑泄愤的念头了,结果电脑也害怕了,让我今天意识到这个错误位置了,哈哈。
好了,回归正题,如果我们编译期间出错,系统会异常,而异常会跟着很大的信息量表示错误原因,就像同下图一样。
不是不让用Try……Catch ……,它可以避免异常,不至于系统直接崩溃,但是,我个人觉得这个应该是程序编译完成之后,哪里可能存在异常就放在哪里,而不是什么地方都用它,对,是它能提示异常,能保证系统在异常以后不崩溃,但是,我们在编译的过程中是为了轻松?还是为了什么?相信大家在机房重构的时候D层出的错误肯定不在少数,然后系统提示的什么(在加了Try……Catch
……之后),是“数据库转换到Integer类型失败”,这是什么玩意?你懂?反正我不懂!是,敲的多了我们就知道是什么哪里出错了,可是我们最多知道在什么范围,你知道确切的错误信息?别逗我,经过大家用了Try……Catch …我可找不到确切错误位置。
Try……Catch ……也是为了防止出现的错误解决不了的方法,故而还是有些好处的。还是那句话,这不是在编译过程中该考虑的,而应该在调错阶段才加入的,那时候才会有更深的意思,否则加早了只会阻碍我们发现错误,这对我们以后一定会产生恶劣影响的!
以上建议仅供参考,随个人喜好就好!
相关文章推荐
- 如何优雅地处理前端异常?
- C#异常处理详解
- 轻松学习C#的异常处理
- PHP异常处理Exception类
- SQL Report Builder 报表里面的常见问题分析
- JS异常处理的一个想法(sofish)
- asp.net SqlParameter关于Like的传参数无效问题
- asp.net SqlParameter如何根据条件有选择的添加参数
- PHP 的异常处理、错误的抛出及回调函数等面向对象的错误处理方法
- PHP如何抛出异常处理错误
- PHP中的错误处理、异常处理机制分析
- js中的异常处理try...catch使用介绍
- php5编程中的异常处理详细方法介绍
- php异常处理使用示例
- Asp.net Mvc 身份验证、异常处理、权限验证(拦截器)实现代码
- javascript 异常处理使用总结
- java多线程中的异常处理机制简析
- 深入理解Java编程中异常处理的优劣
- 分享一个php 的异常处理程序
- 简单了解Java编程中对异常处理的运用