|
前言
这几个月以来，我们有几个小组都在采用JAVA为不同的客户进行WEB应用开发。我们在开发系统过程中不断遭遇到了系统抛出的异常及错误。而且，似乎某些异常及错误感觉很熟悉（即老是出现！）。最近，我对这些小组进行项目的LOG文件进行了简单的分析；针对JAVA WEB应用开发过程中经常遇到的几种异常、错误，得到一些统计结果。
何谓健壮性，即在硬件发生故障、输入的数据无效或操作错误等意外环境下，系统能做出适当响应的程度。所谓更健壮的开发方式指基于增强健壮性要求的开发方式。
本文主要讨论健壮性要求中的"在输入的数据无效或操作错误等意外环境下"，系统仍能做出适应响应的开发方式，同时也对如何减少不正确引用系统外部资源而引起系统异常的解决方法进行讨论。
一、 LOG异常出现统计结果
前面说到我们的几个小组在开发过程中不断遭遇到Java抛出完成相同的异常或错误时(有几个老是出现！)，我注意到一些异常或错误信息关键字。由此，我编写了一个简单的SHELL脚本，对项目小组所使用服务器的运行LOG中这些异常或错误关键字出现的频率进行了分析统计；显然仅统计某单词的的出现频率而得到的统计结果并不是一种很精确的统计；即使如此，我认为这个结果也可能对系统健壮性的提高能提供一些有益的线索。
表 1-1 服务器LOG分析结果
| 异常或错误名称 |
项目1 |
项目3 |
项目3 |
均值 |
| Exception |
35581 |
2361 |
28429 |
-- |
| java.sql.SQLException |
17806 |
100 |
663 |
18.87 |
| Java.lang.NullPointerException |
15957 |
545 |
7364 |
31.28 |
| Java.lang.NumberFormatException |
232 |
107 |
34 |
1.77 |
| Java.lang.StringIndexOutOfBoundsException |
113 |
0 |
0 |
0.11 |
| Java.lang.Exception |
172 |
0 |
1316 |
1.70 |
| Java.lang.NoClassDefFoundError |
4 |
174 |
0 |
2.46 |
| Java.lang.Error |
830 |
129 |
1830 |
4.74 |
| Others |
467 |
1306 |
17222 |
39.07 |
从以上LOG分析的统计图中，我们可以很轻易看出：
- 有三成以上的错误是java.lang.NullpointerException对象空指针错误；（本文讨论目标）
- 约有近二成java.lang.SQLException错误（本文暂不讨论这类JDBC相关错误）；
- 近一成的错误是由于Java.lang.NoClassDefFoundError，Java.lang.Error 引起的，（本文主要讨论目标）
- 另一些错误是由于 java.lang.NumberFormatException, Java.lang.StringIndexOutOfBoundsException引起。（本文主要讨论目标）
- 其他类型异常或错误：本文暂不讨论。
二、 更健壮的开发方式
通常，为了达到开发出健壮的JAVA应用系统的目的，就必须考虑到"输入的数据无效或操作错误等"意外情况可能发生，因而得要遵循更多的规则，从而减少系统异常或错误出现的频率，实现更高系统健壮性。本文所建议使用的开发方式及示范主要是针对Java Web 应用开发者；同时也适用于您所进行的常规JAVA项目。
下面，我开始对得到的统计结果中的这些异常及错误进行一些分析：
- 空指针错误 java.lang.NullPointerException
上面的统计结果显示，我们的项目结果有近三成或更多的异常是空指针异常，这说明空指针异常可能很常见。实际上，我相信100%的JAVA程序员都会对空指针异常十分熟悉。
使用基本的JAVA数据类型，变量的值要么已经是默认值，如果没有对其正常赋值，程序便不能通过编译，因此使用基本的JAVA数据类型(double,float,boolean,char,int,long)一般不会引起空指针异常。由此可见，空指针异常主要跟与对象的操作相关。
下面先列出了可能发生空指针异常的几种情况及相应解决方案：
- 不管对象是否为空就直接开始使用。
(JSP)代码段1：
out.println(request.getParameter("username"));
描述：
代码段1的功能十分简单，就是输出用户输入的表单域"username"的值。
说明：
看上去，上面的语句找不出什么语法错误，而且在大多数情况下也遇不到什么问题。但是，如果某个用户在输入数据时并没有提供表单域"username"的值，或通过某种途径绕过表单直接输入时，此时request.getParameter("username")的值为空（不是空字符串，是空对象null。），out对象的println方法是无法直接对空对象操作，因此代码段1所在的JSP页面将会抛出"java.lang.NullPointerException"异常。
- 即使对象可能为空时，也调用java.lang.Object或Object对象本身的一些方法如toString(), equals(Object obj)等操作。
(JSP)代码段2：
String userName = request.getParameter("username"); If (userName.equals("root")) {// 实际操作….}
|
描述：
代码段2的功能是检测用户提供的用户名，如果是用户名称为"root"的用户时，就执行一些特别的操作。
说明：
在代码段2中，如果有用户没有提供表单域"username"的值时，字符串对象userName为null值，不能够将一个null的对象与另一个对象直接比较，同样，代码段2所在的JSP页面就会抛出(java.lang.NullPointerException)空指针错误。
(JSP)代码段3：
String userName = session.getAttribute("session.username").toString();
描述：
代码段3的功能是将session中session.username的值取出，并将该值赋给字符串对象 userName。
说明：
在一般情况下，如果在用户已经进行某个会话，则不会出现什么问题；但是，如果此时应用服务器重新启动，而用户还没有重新登录，（也可能是用户关闭浏览器，但是仍打开原来的页面。）那么，此时该session的值就会失效，同时导致session中的session.username的值为空。对一个为null的对象的直接执行toString()操作，就会导致系统抛出(java.lang.NullPointerException)空指针异常。
解决方案：
为了确保进行操作或引用的对象非空，假若我们要对某对象进行操作或引用，我们首先去检查该对象是否已经实例化且不为空；并且在系统中加入针对对象为空时情况的处理。
如：采用String对象保存用户提交的结果；在如果涉及对象的操作时，先检测其是否为空后，检查到对象为空后，可再选择进行以下任一种处理方式：
- 处理方式 1) 检查到对象为空时，设置对象值为空字符串或一个默认值；
- 处理方式 2) 检测到对象为空时，根本不执行某操作，直接跳转到其他处理中。
- 处理方式 3) 检查到对象为空时，提示用户操作有错误。
将代码段2按以上方式进行改写，得到：
方式1：
String userName = request.getParameter("username"); // 该变量值为空时，转化为默认空字符串If (userName == null) userName = ""; If (userName.equals("root")) {// 实际操作….}
|
方式2：
String userName = request.getParameter("username"); // 该变量值为空时，转化为默认空字符串，不执行有关操作。 If (usreName != null){ If (userName.equals("root")) {// 实际操作….} }
|
方式3：
String userName = request.getParameter("username"); // 该变量值为空时，转化为默认空字符串，不执行有关操作。 If (usreName == null){ // 提示用户输入信息为空 }
|
实际中，上面提供到三种处理方式也同样适用于其他异常的处理：
- 异常处理方式 1) 检查到异常出现，设置对象值为空字符串或一个默认值；
- 异常处理方式 2) 检测到异常出现，根本不执行某操作，直接跳转到其他处理中。
- 异常处理方式 3) 检查到异常出现，提示用户操作有错误。
- 格式化数字错误 java.lang.NumberFormatException
(JSP)代码段3：
String s_memberid = request.getParameter("memberid");int i_memberid = Integer.parseInt(s_memberid);//….其他操作
|
描述：
以上代码段的作用是将用户提交的表单域memberid的值转化为整数。
说明：
如果用户输入正确的数字如：1082，不会有什么问题。然而，如果用户输入T1082时，由于T1082不是合法的数字格式，JAVA无法将其转化为合适的数字，导致抛出java.lang.NumberFormatException数字格式化异常。
解决方案：
在任何用到字符串转化为数字时，捕捉异常，对异常情况进行处理按异常处理方式1：检查到异常发生，即赋给某变量一个默认值；（可能在某些情况下导致一其他程序错误[比方说其他模块中并未处理您所赋予的默认值情况，可能导致一些异常或错误出现。]）按异常处理方式3：检查到异常发生，提示用户使用正确的数字格式输入。（实现稍微麻烦一点，但是将错误阻挡在您的模块前[即您提供给其他模块的值均是安全的]。）按这种方法对程序进行改写，在编程时稍微麻烦一点，但这的确会您的模块更加健壮。 将代码段3按以上要求进行改写，得到：
String s_memberid = request.getParameter("memberid");int i_memberid;try{i_memberid = Integer.parseInt(s_memberid);//….其他操作}catch(NumberFormatException nfe){ //方式1：（简单，直接给该编号为一个默认值0；）i_memberid = 0;//方式2：（很简陋的做法，建议使用更友好的提示方式） out.println("<script>alert('您提供的用户编号有误，请重新输入。';history.go(-1);</script>");}
|
- 字符串越界错误 java.lang.StringIndexOutOfBoundsException等字符串类相关错误
代码段4：
String s_all_power = "1010011"; String s_access_power = s_all_power.substring(3,4);
|
描述：
以上代码段功能的功能是获取字符串s_all_power中的第4个字符。
说明：
一般情况下，程序不会有问题，如果由于某种原因，s_all_power长度变短，程序就会抛出字符串错误。
解决方案：对字符串进行截取(substring, charAt)、转换为字节数组(getBytes)，字符数组转换为字符串（valueOf）操作时，先对操作字符串对象的存在性（是否为空）及长度进行检查后，再进行操作。
改写得到：
String s_all_power = "1010011"; if (s_all_power.length>4) String s_access_power = s_all_power.substring(3,4);
| 当然，最好的方法是将这些操作封装到Javabeans 中，使用起来就更方便了。
- 类定义未找到错误 java.lang.NoClassDefFoundError
原因：
- 由于该程序调用到的JAVA类文件没有正确上传；
解决方案：
将JAVA类文件重新上传。
- JAVA类文件已经上传，但应用服务器并未检测到，建议将JSP页面重新更新。
解决方案：
将JSP页面更新并上传；或将应用程序服务器进行重新启动。
- JAVA错误 java.lang.Error
原因:
- 对系统所访问外部资源，未执行关闭操作，导致外部资源大量浪费，最终可能导致系统无法正常运行；
- 对系统所访问的外部资源关闭次数太多，外部系统无法正常处理；
- 所系统访问的外部资源出现异常情况。
解决方案：
- 访问外部资源前，首先检查该资源(如数据库)是否可正常连接或操作。
- 访问外部资源时，如果进行了连接，一定进行关闭操作，并仅进行一次关闭操作。
- 尽量在同一操作中共享外部资源，以减少该操作对资源的消费，提高程序的执行效率。
三、 总结
本文对JAVA项目开发中常见的几种错误进行了统计、分析，提出了经改进的更健壮的编程方式，从而使您开发的系统实现健壮性目标，软件质量获得提升。
在实际项目进行过程中，如果您能遵循本文的开发方式，基本可以使您开发的项目中
java.lang.NumberFormatException、java.lang.StringIndexOutOfBoundsException类异常很少出现或不发生，也会大大降低java.lang.NullPointerException异常和其他异常的发生频率。
有句话说"用户永远是对的"。对于熟悉使用您的系统的人来讲，发生"输入的数据无效或操作错误等"意外情况，可能根本不会遇到，只可惜这只是一个假设；然而是否每个用户都对这个系统那么熟悉呢？想想当您们公司的CEO（或总经理）、客户经理在对客户演示时才是第几次使用该系统？
为了增强系统的健壮性，减少系统直接抛出的异常，可以通过使用更健壮的开发方式。当然，同时意味着：同样的模块实现，您的处理设计将比没有异常处理的设计显得更为复杂。 不过，想想（或回忆到）当系统出现异常时公司领导的反应及用户愤怒的表情，您迟早知道这么做是值得的。
当然，实际情况中遇到的错误会比指本文所提到的异常错误多得多。如果有可能，以后我也会整理出更多来，同时希望如果各位朋友找到减少其他系统异常及错误发生的解决方案，也不妨提出来共享。
| 