我开发的护理不良事件报告模块，今天护理部向我反应“护士长签名”这个功能报错，如下图所示：
ORA-00064: 对象过大以至无法在此 O/S 分配 (%s, %s)
我记忆当中，曾经有人向我反应过此问题，当时没有搞定，改日期这个功能又不常用，我先帮你后台帮你改一下数据吧（信息科常用的一招），时间一长，被我无情遗忘了。
出现问题先不用着急去解决，先还原错误。为了检测用户是不是由有非预期的行为引发的错误。按照预期行为（不改日期，因为签名这个功能，日期一般都是默认的，都不需要修改），我进行了第1次测试第一次测试，结果正常。
按照非预期行为（修改日期），我进行了第2次测试，发现出现了以上错误。
接下来就要查找问题的原因。一开始也没有什么头绪，为这种问题不够明显，不改日期是可以的，改日期就不行。很能断定的是哪里的代码出了问题？既然是日期报错了，分析下这个日期，从哪里来到哪里去？日期首先来自于一个ole对象，通过变量接收，再赋值给了数据窗口，然后再保存进数据库。我发现数据窗口的日期类型（datetime）与代码中的日期类型（date）不一致，隐约感觉到这地方有点问题。
首先我们来回顾一下基础知识。编程语言遇到这种数据类型不一致的情况下，通常两种解决方法，强制类型转换、隐式转换。强制类型转换需要我们自己搞定，比如string（数字）。隐式转换，编程语言尝试着帮你进行数据类型转换。再帮大家延伸一下基础知识，我们说的程序错误分为三种。一种编译型异常、运行时异常、业务逻辑异常。
编译型异常，就是我们常说的语法错误。比如你把import写成improt，少括号等等。
运行时异常，程序跑起来的时候会抛到一种异常。比如内存溢出了，被除数为0等等。
业务逻辑异常，程序跑起来的时候是我们主动向用户抛出来的。比如，门诊收费程序用户录入负数，你就抛出“朕，不做亏本生意，不能录入负数”。此外我在这里插播一条小知识。用户使用程序在看到报错的时候，其实会有点焦虑。我们的报错信息可以有一点的幽默，可以缓解一下用户的焦虑。大家不妨可以尝试一下。
好了，说了这么多我们回到我们刚才那个问题。既然pb本身没有报错的话它选择的是一个“隐式转换”的机制，那是不是pb这种“隐式转换”的机制出现bug。带着这样一个疑问，我尝试使用强制类型转换试试看。将dw_1.object.SIGNRQ1[1] = ld_rq改成dw_1.object.SIGNRQ1[1] =datetime( ld_rq)，再运行测试程序发现正常，神奇的bug就得到了解决。
代码片断
以下程序正常测试运行截图：
你可能会问既然“隐式转换”会存在这样的问题的bug，编程语言去掉“隐式转换”不就好了？答案肯定不能一刀切，其实“隐式转换”主要目的提高编程语言的易用性、减少程序员的使用心智。上面例子不够明显说明问题，不过我再举一个“隐式转换”的例子，你就明白了。比如在数据库里面写日期查询条件怎样做好到简化，mssql写t.riqi>='2020-01-01'，oracle写t.riqi>=to_date('2020-01-01'，'yyyy-mm-dd')，很明显mssql利用“隐式转换”写日期查询条件不用自己写to_date更简单！
网友评论