** 【 ** ** 系统出错信息设计 ** ** 】 ** ** **
详细设计说明书 ** **
文件状态：
[√] 草稿
[ ] 正式发布
[ ] 正在修改
|
文件标识：
|
DWR-WRALM-DS-DTDS
---|---|---
当前版本：
|
0.928
作者：
|
郑力
完成日期：
|
2004-09-28
版 本 历 史
版本 / 状态
|
作者
|
参与者
|
起止日期
|
备注
---|---|---|---|---
草稿
|
郑力
|
|
0.9.918
|
草稿
|
郑力
|
2004-09-21
|
2004-09-21
|
草稿
|
郑力
|
2004-09-28
|
2004-09-28
|
**
**
1 文档介绍
1.1 文档目的
试图阐述系统出错在一个系统中所起重要作用 , 使系统更加健壮 . 系统出错如何设计并运用到系统中 . 以及异常出错信息的维护等情况 .
1.2 读者对象
提示：指出预期的读者。详细设计的读者一般包括项目主管、开发人员、测试人员以及维护人员等。
1.3 参考文档
提示：列出本文档的所有参考文献（可以是非正式出版物），如：
a ．本项目的经核准的计划任务书或合同、上级机关的批文；
b ．属于本项目的其他已发表的文件；
c ．本文件中各处引用的文件、资料、包括所要用到的软件开发标准。
列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。作者，文献名称，出版单位（或归属单位），日期等。
格式例如：
[1] 许新宜、王浩、甘泓等，华北地区宏观经济水资源规划理论与方法，黄河水利出版社， 1997.10 。
1.4 术语与缩写解释
缩写、术语
|
解 释
---|---
DWR
|
水资源所
WRALM
|
水资源配置模型
DN
|
设计 design
DTDS
|
详细设计 detail design
|
|
|
2 体系结构设计
2.1 体系总体结构设计
2.1.1 体系总体设计结构图
其描述为 :
在上图的上部是软件工程系统中所面临的解决问题的部分 . 其中会有错误异常的发生 .
根据编写定制的需要 , 需要错误异常处理机制进行处理 , 根据规则需要 , 错误异常可能会直接返回给相应的发生问题的部分 , 也可能需要交给应用客户端或使用者进行干预从而确定是否返回给发生问题的部分 .
2.1.2 什么是错误异常
简单地说，错误异常代表了应用程序的某种状态 ( 错误或异常状态 ) ，也就是所谓 “ 异常状况 ” 。通常，这种应用程序中出现的异常会产生某些类型的错误，而且异常自身也会采用某些方式来描述错误的状况。当程序中发生异常时，它会沿着函数调用链传递直到发生以下两种情况：发现了能够处理异常的处理器或者异常被扔出应用程序的主要方法，在这种情况之下就会触发缺省的异常处理器。通常也就意味着结束程序的运行。
能够探察错误的一方不知道如何处理错误，知道如何处理错误的一方没有能力探察错误，而直接采用防御性代码来解决，会使得程序的正常结构被打乱，从而带来更多的错误。这种困境是非常难以应对的 —— 费心耗力而未必有回报。因此，更多的人采用鸵鸟战术，对可能发生的错误视而不见，任其自然。
2.1.3 错误异常在系统中的作用
错误异常是一个系统的重要组成部分 . 在调试 , 测试以及运行时都有重要作用 .
在调试阶段 , 能够清楚的告诉软件开发人员 , 在代码的哪行出了错误 , 是什么方法或哪个方法调用了哪个方法 , 存在于哪个文件等情况 . 总之 , 使软件开发人员很清楚的明白哪个地方错了 , 以及形成错误的原因是什么等情况的说明 . 这样便于软件开发人员努力修订自己的程序 , 尽量避免类似情况发生 .
在测试阶段便于测试人员写出测试文档 , 在测试文档中 , 相关人员便于理解并修订原程序 . 需要提供必要的软件开发人员名称 , 软件版本号 , 以及写作时间和运行时间 .
在运行阶段 , 需要提供给用户尽可能的友好信息 , 便于理解和交互 .
2.1.4 错误异常处理机制和原则
由 Try代码块保护的代码所发生的任何异常，甚至包括在不含Try代码块的被调函数或
方法以内的异常都将被 Catch代码块内的代码处理。当然，除非catch代码块自己也扔出了
异常，而在这种情况下异常会被扔到下一个级别更高的 try代码块，哪怕那意味着从当前正
在执行的函数中扔出异常。
异常的 4 条重要规则
- 如果 catch 块有若干个，那么异常将根据其类型被扔给最适当的一个 catch 接受处理。
- 如果没有找到可接受的 catch 块，则异常被从当前的 try 块扔到从调用顺序链中找到的下一个可用的 catch 块。
- 异常对象的类型给出了发生错误本质的重要信息。
- 异常可以通过 throw 关键词显式扔出。
代码就可以选择性地只处理那些有能力处理的错误，同时相信其他问题都会统统交给调用堆栈，哪怕至少作为通知处理。在实际应用中，因为让 CLR 观察扔出的异常对性能有一定的影响，所以使用单个 try 块同时对应多个特殊异常的 catch 语句是检查代码多个特定错误的最佳方式。
2.2 错误异常情况
根据系统应用 , 常见错误异常分为数据存储部分 , 应用部分 , 核心库部分 , 商业层部分 .
数据存储部分 : 主要系统在与数据库产品交互时 , 常见的一些错误 . 比如数据库连接错误 , 数据库对象不存在或数据字符过多 .
应用部分 : 主要是反映用户在键盘输入操作时 , 可能引起的数据类型错误 , 字符长度超过限制等 , 使用鼠标或键盘可能引起的操作错误等 .
核心库部分 : 主要反映系统框架中的一些错误 . 比如数组下标越界 , 数字超出范围等 .
商业层部分 : 主要反映系统中的一些如权限被拒绝 , 输入参数错误等 .
2.2.1 数据存储部分 :
该部分我们在异常中主要使用三个类 :SqlException,OracleException 以及 OleDbExcetion.
建议最后不要用 OdbcException. 其错误代码范围为 : 100000---200000 .
2.2.1.1 SqlServer:
ErrorCode 范围 : 100000--- 200000 --SqlException
2.2.1.2 Oracle:
ErrorCode 范围 : 100000----200000-- OracleException
2.2.1.3 Access:
L 暂缺 )
ErrorCode 范围 : 100000----200000-- OleDbException
2.2.1.4 DB:
L 暂缺 )
ErrorCode 范围 : 100000----200000-- OleDbException
2.2.1.5 Sybase:
L 暂缺 )
ErrorCode 范围 : 100000----200000-- OleDbException
2.2.1.6 MySql:
L 暂缺 )
ErrorCode 范围 : 100000----200000-- OleDbException
2.2.1.7 其它 :
L 暂缺 )
ErrorCode 范围 : 100000----200000—OleDbException
2.2.2 应用部分
此部分根据不同的商业应用或目的不同 , 就有很多的差别 .
所以仅给出错误代码范围 1---100000 . 具体提示信息由软件开发人员 , <SPAN style="FONT-FAMILY: 宋体; mso-ascii-font-family: 'Times New Roman'; ms