错误代码以及错误消息提示-如何更好地管理与维护消息资源
错误代码以及错误消息是开发过程中不可避免会碰到的问题，虽然对于开发技巧并没有多高的要求，但是清晰地管理好这些资源对于整个项目或者产品的开发都是百益而无一害的。
1）明晰代码模块以及更好地梳理代码流程
2）便于PM和前方客户沟通
3）方便校验和国际化处理
从开发的角度，如何更好地管理好这些错误资源文件呢？ 结合平常实际开发经验，总结出从几个方面实现明晰的错误消息管理。
一.错误消息规则
错误消息是一组由JSON格式表示的字符串，例如：{"error_code":"00001","error_message":"Invalid paramter."}，
其中错误代码=模块代码+消息代码，例如假设错误代码共5位，模块代码长度设置为2位，则剩余的3位可以用来表示消息代码，
例如：
| 模块代码 | 模块名称 |
| 00 | 通用模块 |
| 01 | 用户管理 |
| 02 | 文件管理 |
| --- | 其他模块等等 |
例如： 00001，00表示通用模块，001表示在通用模块中具体消息。
二.错误消息定义
错误消息定义流程，遵循从前往后的原则。
1）前端错误消息来源于表单的校验，根据具体表单约束定义错误消息并管理在后端server上。
2）后端错误消息的定义是离不开API，
1）针对每个API，定义错误消息。
2）先抽出每个API通用的错误消息，例如：参数类型不对，Session过期，API名称不存在。
3）每个API的设计者、是闲着根据具体的模块添加错误消息。
3）调用第三方接口错误消息处理，
Http协议以及WSDL协议需要处理Socket Connection Refused 等异常
需要处理第三方接口抛出的业务异常
三.错误消息框架实现
1)前端错误消息校验
定义错误信息资源文件web_errors,在页面上根据不同的locale通过ajax 加载不同的web_errors文件，并把该资源文件组装成error_code=error_message的map形式,方便前端调用。
2.Server层
定义专门的错误资源文件束：errors
使用ResourceBundle或者使用Spring [[MessageSource]] 加载错误资源文件
<bean id="messageSource" class="org.springframework.context.support.ResourceBundleMessageSource" lazy-init="false"> <property name="basenames" value="messages"/> <property name="defaultEncoding" value="UTF-8"/> </bean>
由于ResourceBundle只是支持ISO8859-1编码的文件，因此需要将中文的资源文件使用native2ascii 转换成Unicode（UTF-8)编码的文件，如何将转换？ 其中一个方法为使用Maven native2ascii-maven-plugin 将具体的属性文件转化为unicode编码的即可。
<plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>native2ascii-maven-plugin</artifactId> <version>1.0-beta-1</version> <executions> <execution> <id>native2ascii</id> <phase>compile</phase> <goals> <goal>native2ascii</goal> </goals> <configuration> <encoding>UTF-8</encoding> <workDir>${project.build.outputDirectory}/i18n</workDir> <includes> <include>*.properties</include> </includes> </configuration> </execution> </executions> </plugin>
四。开发时如何避免资源文件冲突
1）将web端的错误信息资源文件和后端错误信息资源文件分开
2）多个开发人员开发时，为避免多人修改同一个错误资源文件导致冲突，可以根据模块分割成多个小文件，在打包时将这些小文件合并成一个大文件即可。
总结
错误资源管理其实也可以用于普通的资源管理，这里为什么要突出错误资源管理，这是因为在开发过程中，发现平常重开发轻错误处理，并没有加快开发进度，反而在某种程度上延误了项目进度。项目资源管理是整个项目开发中很细节的一块，就如何处理好这些细节，节约项目开发时间，将自己平时做的方法做了一些总结。这些总结肯定也会有局限性，在来日的开发过程中，发现更好的方法，我会继续跟进。
