错误处理规范

一、整体规范

1.      按照错误类型，通常的处理方式如下：

 

错误类型	范围	处理方式
操作员错误	与人机界面交互时不满足输入规则、输入范围等发生的错误	校验用户输入 提示正确规则 强制其改正
运行时错误	与外部资源交互时发生的错误，如网络、文件系统、数据库、其它业务应用系统等	记录并抛出异常 其它详见“异常处理规范”
程序员错误	与客户模块交互时不满足前置条件后置条件发生的错误，如类库被其他程序员调用时参数超出范围等	使用断言

2.      按照调用类型，通常的处理方式如下：

 

调用类型	处理方式
同步调用	对有能力处理的异常，捕获并处理之 对原始信息过于技术化的异常，捕获并包装之，重新抛出 在调用的中间层，对未知异常保持沉默 在调用的最高层，必须捕获所有异常，避免本身进程或宿主进程崩溃 其它详见“异常处理规范”
异步调用	异步调用一般不应有任何返回值 服务方最好以同样的方式返回正常信息和错误信息，即正常信息是通过通知的方式返回的话，错误信息也应该通过通知的方式返回；正常信息是通过主动查询得到的话，错误信息也应该通过主动查询得到

 二、异常处理规范

 异常应该是分层的

 1. 异常定义

• 每个模块应该有自己的应用程序异常类型层次，从本模块主动抛出的应用程序异常都应该属于该异常类型层次，客户代码可以只捕捉该层次的基类（？）
• 应用程序的所有自定义异常都应该从开发平台提供的“应用程序异常基类”派生
• 中间件等平台程序的运行时异常都应该从开发平台提供的“运行时异常基类”派生（？）
• 中间件等平台程序的运行时错误都应该从开发平台提供的“错误基类”派生（？）

 2. 异常捕获

• 对有能力处理的异常，捕获并处理之
• 在调用的中间层，对未知异常保持沉默
• 在调用的最高层，必须捕获所有异常，避免本身进程或宿主进程崩溃
• 记录捕获到的每个原始异常的信息

 3. 异常抛出

• 每个模块应使用本模块所能得知的最精确的错误原因报告异常信息
• 如果有原始异常，在重新抛出的自定义异常中附加原始异常的信息

 三、几点说明

 

 1. 错误处理与日志系统

• 错误处理不等同于日志系统，日志系统只是错误信息的一种记录手段
• 错误信息的输出应全部调用日志系统来完成

 2. 程序员错误与运行时错误

• 接口函数的前置条件，应该是一种规范，是客户程序员必须遵守的约定；客户程序员违反了约定，程序将产生异常或不可预知的错误；对于这类约定，不应该需要有运行时的代码检查 ；比如如果你的接口函数的一个参数不能为null，而你在函数开始部分程序里写：

         if(xxx == null){

              throw new someException();

}

你的代码实际上允许该参数为null，因为你对null的情况进行了运行时处理；尽管你在文档里声明该参数不能为null，但如果客户程序员遵守了约定，那么你这段检查代码就是冗余的

• 当你对参数没有任何检查就进行了使用，而非法的参数值导致了错误，此时有两种情况： 如果你在接口函数说明里列出了参数不允许的非法取值，那么客户程序员应该修改程序避免传入非法值，该类错误称为程序员错误；如果你没有说明，那么你应该修改函数，处理非法参数
• 不是所有的限制条件在文档里说明一下，就可以把责任扔给客户程序员了，有一些错误必须处理：特别是客户程序员不需要import你的package就可以和你的接口交互的情况，如socket服务器 ，你必须在socket服务程序内部检查所有接收到的数据，拒绝错误的请求，否则极易遭到攻击

 3. 错误代码与异常

• 不应该使用bool值来返回成功与否，bool返回值只应用在真正查询bool状态的操作中，如   bool   IsDirty () ， bool   hasNext () 等
• 整形或bool型的错误代码返回值强迫客户程序员检查每一次调用，应用异常取代之

 

“世界上并不存在完全无错的程序”，我们不讨论它是不是一条真理。但它的确是一条警语，它告诫我们在编写程序时一定要注意尽可能地避免错误。

程序运行出错时会超出程序员的控制，使得程序“南辕北辙”，不仅无法正常完成功能，而且还会出现一些可怕的事情。

由于程序设计的错误而引起的事故数不胜数，损失最巨大的是美国的一次火箭发射，在那次悲剧中，在程序中由于错把“，”写成了“；”，却使得火箭在天上爆炸，所以为防止程序设计错误花再大的人力、物力也是应该的。

以上这段话说明了错误处理的重要性。

　　最有效的解决方法是在程序设计是，有意识地加入一些机制，使其能够在运行时检测自己，在错误失控之前，报告出来。

最常见的一种错误处理是为每一个方法（其它语言，就是每一个函数）返回一个状态值，用来指示该方法是否成功、正确地完成了任务。当调用这个方法的程序收到了一个错误的状态值，就能够得知程序出错了，再采取有效的措施避免这个错误引起的问题（最简单的方法就是退出程序，或给出提示提醒操作者）。

首先让我引入一个概念：错误模式

所谓的错误模式，我理解和设计模式所涉及到的知识应该是一样的，错误模式就是已发出的错误和程序中潜在的错误之间的重复出现的相互关系。这种概念对编程来说并不是新鲜的，随便极端编程的出现，RUP，单元测试只能解决一部分存在的问题，所以我们采用错误模式，一个错误的出现，只要遵循我们可以识别的错误模式中的一种，随可以得知这个错误的原因并且纠正它。

有兴趣的朋友可以搜搜错误模式，有许多文章介绍的。以下是我要介绍的二种错误处理方式。

一 构造错误异常:

构造错误异常，这里就利用了错误模式去发现错误并纠正它，首先让看一段代码：

InvalidNameException.java

class InvalidNameException extends Exception{
    public InvalidNameException(){
    }
}

程序中：

public User validate(String userName,String password) throws InvalidNameException{
        if(userName.equals("java")){
        }else{
            throw new InvalidNameException();
        }
        //return null;
    }

以上这段代码，意思就是，如果用户名不为java的话，那么就抛出InvalidNameException()这个异常，于是我们就可以成功的捕捉这个异常，并发出提示或警告。这样构造一个强大的错误处理集合就可以对程序内部或外部进行错误处理。

二 key/values方式.

    根据配置文件查找相应的错误信息，并显示给用户，struts的错误处理方式就采用了这个（其实我说的二种都采用了）。首先看一下以下代码：

ErrorMessage error=new ErrorMessage();
if(!username.equals(“java”)){
    error.add(“ERROR.LOGIN.USERNAME.FAILED”);
}

    创建一个ErrorMessage对错误进行处理，如果返回空的error对像的话，说明没有错误，如果返回一个非空的error对像，那么就跳转到error.jsp页面，并捕捉这个错误。

错误信息配置文件：

LOGIN = 用户登陆

ERROR.LOGIN.EMPTY_INPUT = 登陆失败：无效输入！

ERROR.LOGIN.EMPTY_INPUT.DESC = 可能输入了空值或其他非法字符。

ERROR.LOGIN.USERNAME.FAILED = 用户名错误

ERROR.LOGIN.USERNAME.DESC = 请后退重试，检查您的用户名是否输入正确!

以上两种方式结合于log4j一起使用，可以达到对错误处理的要求，我的思想就是在系统层，如方法内，抛出异常处理，在表现层对用户输入和相关处理用key/values方式处理，这种方式我以前在写程序的时候就在用，现在又搬出来希望能听到回复的声音，讨论一下，看一看有没有更好的解决方式，由于本人水平有限，目前的错误处理设计依然是基于这个去做的。