目录

1、吧啦吧啦吧啦

1.1、代码自我意识

1.2、代码功能安全

1.3、代码保密性

1.4、代码执行完整性

1.5、代码的容错机制与自我调节

2、设计观与方法论

2.1 设计观与代码容错机制、自我调节

2.2 问题是否能够被解决

2.2.1 意识行为是否具有虚拟性

2.2.2 思维是否具有方向性

2.3 问题与问题解决

2.4 软件与问题

3、代码容错机制与异常

4、一个微型实例

4.1 业务逻辑异常

4.2 执行控制异常

4.3 系统级别异常

5、代码容错机制与自我调节总结

---

“行为”“自我调节”是心理学和日常生活中比较常见的用语，意义还是很明确的，那么，无论从信息加工论的认知观来看，还是从类比人的心理活动和行为、对代码构建一种新的描述方式来看，“代码行为异常”“代码自我调节”意义都是很明确的。

 

1、吧啦吧啦吧啦

吧啦吧啦吧啦是什么？补习时，学生模仿我讲道理的时候常常会说“吧啦吧啦吧啦”以示略过。在这里，它就算是一些表达我观点概念性词语吧。这些概念就是电影里的快镜、远景或背景旁白，虽然只有廖廖几个，却足以勾画我的道理的基本框架，成为电光石火间的一道思绪掠影。

 

1.1、代码自我意识

“代码是具有自我意识的。”

“年轻人，别太高大上。”

代码就是一篇由程序设计语言承载的“小说”，或短篇或中篇或长篇，不同于文学小说的是，代码反映的内容只有一项：这个问题怎么解决。说代码具有自我意识，这是基于既把代码当作、又是代码能够成为独立对象的。程序运行过程中对自身、对运行环境的感知与评价就是代码的自我意识。这对于大多数软件来说，是处于正常业务逻辑之外的，也是不必须的。而说到自我意识，就不得不面对终极之问：我是谁？我存在吗？这种终极之问的答案在同一个维度内和同一个形式系统内很难回答：在找到更高级的智慧生命形态之前，我思故我在可以通过感知思考过程证明客观实在的“我”，但是代码却很难从同一代码系统内的指令层面上对为用户服务的自己、虚拟环境下的自己和反编译下的自己做出绝对区分。软件漏洞问题实际上就是涉及方方面面的逻辑检测、异常捕获是否得到充分展开的问题。如果存在充分展开就会在代码层面上形成一个良好的自我意识系统。

 

1.2、代码功能安全

软件是为解决一定问题、实现某个业务功能而存在的，软件代码中为确保业务功能得以正常实现的、系统或局部机制下的、在常规业务逻辑流程之外的代码行为都属于代码功能安全范畴，包括代码保密机制、代码执行完整性检查、代码容错机制与自我调节，不包括业务逻辑内的身份验证、使用授权、通信加密等。软件处理的业务越重要，代码功能安全问题就越突出。代码功能安全机制很像带有独立功能的单位的秩序保障机制，有了它，软件的功能才得以平稳而有序地展开，这个世界才会有另一个精彩绝伦的故事，给世间创造一笔笔财富。对于大多数软件来说，一般只要求能实现正常的业务逻辑、一定期限内稳定运行即可，对软件功能安全的意识和要求不高。软件一般会有代码容错和自我调节机制，较高层次的软件支持执行完整性，更高一级的系统（更底层生态的系统）才可能会在前两者基础上要求代码保密。

 

1.3、代码保密性

不记得是谁说过，比陆地更广阔的是海洋，比海洋更广阔的是天空，比天空更广阔的是你我的心胸。可是，我就要告诉你，人的心胸再大，也装不下不应该知道的秘密。保密是一个老得掉牙的话题。底层基础的、原理的、原子的以及核心的代码往往是双重非公开，既是用户非公开，也是普通设计员或技术维护员非公开，还是形式非公开。用户眼里，软件永远只是一个个交互界面。而普通设计员或技术维护员，只能访问和修改公开性的授权代码。形式非公开，是指即便通过一定技术手段，也只能得到一行行的形式代码，即以或二进制指令、或机器指令、或字节码等形式而存在的代码，但却只是一种加密形式，非原来代码本身。这也是一种认知非公开。说到这里，我不得不赞叹一句：是谁发明了加密这种极具智慧的方法？比如说，小三（2）班只有李雷会讲英文，一天转来一位新加坡的新生露西。韩梅梅只想和露西讨论习题的时候，会偷偷地把露西拉到一个没人的地方，而当李雷只想和露西讨论的时候，则可以正大光明地于阳光之下用英文和露西交流，其他同学同样只有蒙圈的资格。

 

1.4、代码执行完整性

代码执行完整性问题实际上是关于“我是我吗”或“你是谁”的问题，是正常业务逻辑内或代码系统本身在“自我信息感知”这一层面上，确保自己或对方是合乎要求的自己（自然独立实体）或对方（非冒充者）的一种身份确认和保证特性。这对于基于网络传输的软件来说无疑是意义重大的。关于执行完整性，我在网上找到一些资料，一起来感受一下。

基于完整性的执行控制设计与实现，这是在百度学术中看到的一篇论文，摘要：为防止外来漏洞程序(如来自网络或U盘)威胁系统，本文在LSM框架下构建一个基于完整性的执行控制安全模块，控制这些程序的执行。为区分这些程序，本文定义了完整级，将这些程序标记为最低完整级，普通用户不能执行这些程序，而超级用户可以在构建的沙箱中执行这些程序，从而确保系统的安全。

从摘要看出，这种执行完整性控制是环境级别的，不是软件自身自发的，而是来自外在运行环境的监测。类似这种设计的检测与控制模式在杀毒软件或其他安全软件中用的比较多。

一种程序执行完整性保护方法和系统 [发明]，这是在专利之星系统中检索到的内容，摘要: 本发明公开一种程序执行完整性保护方法，包括：根据跳转指令，将程序分割成顺序执行的程序块，在每个程序块的起始位置插入校验值标识CK_FLAG和校验值CK_VALUE；在程序运行时，进行实时程序块校验值计算，并和预先计算好的程序块校验值进行比较，在程序块受到破坏或者没有按照预期执行程序块时给出警报信号。

从摘要来看，这是一种比较典型的完整性检查，可以和某些类型的文件在网络传输中的校验检查做类比，主要检查程序当前的执行指令或模块是否是按照设计者最初的设计进行的。如果是，那么这种执行是完整的，否则是不完整的，即代码的当前行为不是代码本身、而是外在因素发起的，当前的代码行为环境是虚拟而非真实操作系统。执行完整性检查既是一种智慧活，需要一定的策略来确定代码的自然独立和真实性，也是一种智力活，检查策略将以系统性的代码形式体现出来，即能够被翻译成合适的计算科学技术和方法。我能通过我正在思考确定我的客观实在性，但我又是怎么知道我在思考的？很明显，自我感知。也就是说，要把策略转化为形式代码。

以上两种方式侧重点有所不同，但可大致归类于执行完整性检查，第一种是来自代码外部的，基于代码的完整性作出安全风险评估，并给予不同的执行环境，以尽可能地减少对真实的系统带给破坏性的影响。第二种是来自代码内部的，通过基于设计流的校验码来确定当前的代码行为是发自原始的自身。

 

1.5、代码的容错机制与自我调节

我首先来列举一下代码有哪些异常吧。代码异常有两种级别：系统级别和软件级别。软件级别的异常又分执行控制异常和业务逻辑异常。

系统级别异常：软件正常运行所需要的资源，如权限、内存空间、某种设备资源使用通道、所依赖的系统组件等，操作系统因某种原因无法给予正常提供而导致的访问、修改、运行异常，即代码无法正常进行当前阶段的业务处理行为，实现某个功能。

执行控制异常：执行控制异常即行为流向异常。在当前阶段，根据不同的输入，代码的行为会按照业务处理逻辑有条不紊地指向某一个方向。也即，在控制系统的协调下数据和实现业务的功能模块有序地交互作用。当这种有条不紊和有序受到破坏，也可看作是实现业务处理或软件本体处理及相关处理要求的“规律”受到破坏，从而引发执行控制异常。

业务逻辑异常：也可以称为问题求解异常。当实现某个功能所需的条件不成立时，求解过程或业务处理过程脱离预定逻辑，便发生业务逻辑异常。另一种情况是，数据是正确的，条件是提供的，但是解决方法不对。总之，无法实现正常的业务处理，解决问题。

上面只是代码异常的两种级别和分类，在不同的应用情境、语境下，这些异常都可以包含非常丰富的实际内涵。