java错误搜集

1. 纠结的同名
现象
很多类的命名相同（例如：常见于异常、常量、日志等类），导致在import时，有时候张冠李戴，这种错误有时候很隐蔽。因为往往同名的类功能也类似，所以IDE不会提示warn。
解决
写完代码时，扫视下import部分，看看有没有不熟悉的。替换成正确导入后，要注意下注释是否也作相应修改。
启示
命名尽量避开重复名，特别要避开与JDK中的类重名，否则容易导入错，同时存在大量重名类，在查找时，也需要更多的辨别时间。
2. 想当然的API
现象
有时候调用API时，会想当然的通过名字直接自信满满地调用，导致很惊讶的一些错误：
示例一：flag是true？
boolean flag = Boolean.getBoolean("true");


可能老是false。
示例二：这是去年的今天吗（今年是2012年）？结果还是2012年：
Calendar calendar = GregorianCalendar.getInstance();
calendar.roll(Calendar.DAY_OF_YEAR, -365);


下面的才是去年：
calendar.add(Calendar.DAY_OF_YEAR, -365); 


解决办法
问自己几个问题，这个方法我很熟悉吗？有没有类似的API? 区别是什么？就示例一而言，需要区别的如下：
Boolean.valueOf(b) VS Boolean.parseBoolean(b) VS Boolean.getBoolean(b);


启示
名字起的更详细点，注释更清楚点，不要不经了解、测试就想当然的用一些API，如果时间有限，用自己最为熟悉的API。
3. 有时候溢出并不难
现象
有时候溢出并不难，虽然不常复现：
示例一：
long x=Integer.MAX_VALUE+1;
System.out.println(x);


x是多少？竟然是-2147483648，明明加上1之后还是long的范围。类似的经常出现在时间计算：
数字1×数字2×数字3…
示例二：
在检查是否为正数的参数校验中，为了避免重载，选用参数number, 于是下面代码结果小于0，也是因为溢出导致：
Number i=Long.MAX_VALUE;
System.out.println(i.intValue()>0);


解决
1 让第一个操作数是long型，例如加上L或者l（不建议小写字母l，因为和数字1太相似了）；
2 不确定时，还是使用重载吧，即使用doubleValue()，当参数是BigDecimal参数时，也不能解决问题。
启示
对数字运用要保持敏感：涉及数字计算就要考虑溢出；涉及除法就要考虑被除数是0；实在容纳不下了可以考虑BigDecimal之类。
4. 日志跑哪了？
现象
有时候觉得log都打了，怎么找不到？
示例一：没有stack trace！
 } catch (Exception ex) {
    log.error(ex);
 }


示例二：找不到log！
} catch (ConfigurationException e) {
    e.printStackTrace();
}


解决
3 替换成log.error(ex.getMessage(),ex);
4 换成普通的log4j吧，而不是System.out。
启示
5 API定义应该避免让人犯错，如果多加个重载的log.error(Exception)自然没有错误发生
6 在产品代码中，使用的一些方法要考虑是否有效，使用e.printStackTrace()要想下终端(Console)在哪。
5. 遗忘的volatile
现象
在DCL模式中，总是忘记加一个Volatile。
private static CacheImpl instance;  //lose volatile
public static CacheImpl getInstance() {
    if (instance == null) {
        synchronized (CacheImpl.class) {
            if (instance == null) {
                instance = new CacheImpl (); 
            }
        }
    }
    return instance;
}


解决
毋庸置疑，加上一个吧，synchronized 锁的是一块代码（整个方法或某个代码块），保证的是这”块“代码的可见性及原子性，但是instance == null第一次判断时不再范围内的。所以可能读出的是过期的null。
启示
我们总是觉得某些低概率的事件很难发生，例如某个时间并发的可能性、某个异常抛出的可能性，所以不加控制，但是如果可以，还是按照前人的“最佳实践”来写代码吧。至少不用过多解释为啥另辟蹊径。
6. 不要影响彼此
现象
在释放多个IO资源时，都会抛出IOException ，于是可能为了省事如此写：
public static void inputToOutput(InputStream is, OutputStream os,
           boolean isClose) throws IOException {
    BufferedInputStream bis = new BufferedInputStream(is, 1024);
    BufferedOutputStream bos = new BufferedOutputStream(os, 1024);  
    ….
    if (isClose) {
       bos.close();
       bis.close();
    }
}


假设bos关闭失败，bis还能关闭吗？当然不能！
解决办法
虽然抛出的是同一个异常，但是还是各自捕获各的为好。否则第一个失败，后一个面就没有机会去释放资源了。
启示
代码/模块之间可能存在依赖，要充分识别对相互的依赖。
7. 用断言取代参数校验
现象
如题所提，作为防御式编程常用的方式：断言，写在产品代码中做参数校验等。例如：
private void send(List< Event> eventList)  {
    assert eventList != null;
}


解决
换成正常的统一的参数校验方法。因为断言默认是关闭的，所以起不起作用完全在于配置，如果采用默认配置，经历了eventList != null结果还没有起到作用，徒劳无功。
启示
有的时候，代码起不起作用，不仅在于用例，还在于配置，例如断言是否启用、log级别等，要结合真实环境做有用编码。
8. 用户认知负担有时候很重
现象
先来比较三组例子，看看那些看着更顺畅？
示例一：
public void caller(int a, String b, float c, String d) {
    methodOne(d, z, b);
    methodTwo(b, c, d);
}
public void methodOne(String d, float z, String b)  
public void methodTwo(String b, float c, String d)


示例二：
public boolean remove(String key, long timeout) {
             Future< Boolean> future = memcachedClient.delete(key);
public boolean delete(String key, long timeout) {
             Future< Boolean> future = memcachedClient.delete(key);




示例三：
public static String getDigest(String filePath, DigestAlgorithm algorithm)
public static String getDigest(String filePath, DigestAlgorithm digestAlgorithm)


解决
7 保持参数传递顺序；
8 remove变成了delete，显得突兀了点， 统一表达更好；
9 保持表达，少缩写也会看起来流畅点。
启示
在编码过程中，不管是参数的顺序还是命名都尽量统一，这样用户的认知负担会很少，不要要用户容易犯错或迷惑。例如用枚举代替string从而不让用户迷惑到底传什么string, 诸如此类。
9. 忽视日志记录时机、级别
现象
存在下面两则示例：
示例一：该不该记录日志？
catch (SocketException e)
{
    LOG.error("server error", e);
    throw new ConnectionException(e.getMessage(), e);
}   


示例二：记什么级别日志？
在用户登录系统中，每次失败登录：
LOG.warn("Failed to login by "+username+");


解决
10 移除日志记录：在遇到需要re-throw的异常时，如果每个人都按照先记录后throw的方式去处理，那么对一个错误会记录太多的日志，所以不推荐如此做；但是如果re-throw出去的exception没有带完整的trace( 即cause)，那么最好还是记录下。
11 如果恶意登录，那系统内部会出现太多WARN，从而让管理员误以为是代码错误。可以反馈用户以错误，但是不要记录用户错误的行为，除非想达到控制的目的。
启示
日志改不改记？记成什么级别？如何记？这些都是问题，一定要根据具体情况，需要考虑：
12 是用户行为错误还是代码错误？
13 记录下来的日志，能否能给别人在不造成过多的干扰前提下提供有用的信息以快速定位问题。
10. 忘设初始容量
现象
在JAVA中，我们常用Collection中的Map做Cache,但是我们经常会遗忘设置初始容量。
cache = new LRULinkedHashMap< K, V>(maxCapacity);


解决
初始容量的影响有多大？拿LinkedHashMap来说，初始容量如果不设置默认是16，超过16×LOAD_FACTOR,会resize(2 * table.length),扩大2倍：采用 Entry[] newTable = new Entry[newCapacity]; transfer(newTable)，即整个数组Copy， 那么对于一个需要做大容量CACHE来说，从16变成一个很大的数量，需要做多少次数组复制可想而知。如果初始容量就设置很大，自然会减少resize, 不过可能会担心，初始容量设置很大时，没有Cache内容仍然会占用过大体积。其实可以参考以下表格简单计算下, 初始时还没有cache内容, 每个对象仅仅是4字节引用而已。
memory for reference fields (4 bytes each);
memory for primitive fields
Java type Bytes required
boolean 1
byte  
char 2
short  
int 4
float  
long 8
double  
启示
不仅是map, 还有stringBuffer等，都有容量resize的过程，如果数据量很大，就不能忽视初始容量可以考虑设置下，否则不仅有频繁的 resize还容易浪费容量。

在Java编程中，除了上面枚举的一些容易忽视的问题，日常实践中还存在很多。相信通过不断的总结和努力，可以将我们的程序完美呈现给读者。

注意事项：

（1）所有数据都应该隐藏在所在的类的内部。
　　（2）类的使用者必须依赖类的共有接口，但类不能依赖它的使用者。
　　（3）尽量减少类的协议中的消息。
　　（4）实现所有类都理解的最基本公有接口[例如，拷贝操作（深拷贝和浅拷贝）、相等性判断、正确输出内容、从ASCII描述解析等等].
　　（5）不要把实现细节（例如放置共用代码的私有函数）放到类的公有接口中。
　　如果类的两个方法有一段公共代码，那么就可以创建一个防止这些公共代码的私有函数。
　　（6）不要以用户无法使用或不感兴趣的东西扰乱类的公有接口。
　　（7）类之间应该零耦合，或者只有导出耦合关系。也即，一个类要么同另一个类毫无关系，要么只使用另一个类的公有接口中的操作。
　　（8）类应该只表示一个关键抽象。
　　包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包影响，则将对包中的所有类产生影响，而对其他的包不造成任何影响 .（9）把相关的数据和行为集中放置。
　　设计者应当留意那些通过get之类操作从别的对象中获取数据的对象。这种类型的行为暗示着这条经验原则被违反了。
　　（10）把不相关的信息放在另一个类中（也即：互不沟通的行为）。
　　朝着稳定的方向进行依赖。
　　（11）确保你为之建模的抽象概念是类，而不只是对象扮演的角色。类应当统一地共享工作。
　　（13）在你的系统中不要创建全能类/对象。对名字包含Driver、Manager、System、Susystem的类要特别多加小心。
　　规划一个接口而不是实现一个接口。
　　（14）对公共接口中定义了大量访问方法的类多加小心。大量访问方法意味着相关数据和行为没有集中存放。
　　（15）对包含太多互不沟通的行为的类多加小心。
　　这个问题的另一表现是在你的应用程序中的类的公有接口中创建了很多的get和set函数。
　　（16）在由同用户界面交互的Java面向对象模型构成的应用程序中，模型不应该依赖于界面，界面则应当依赖于模型。
　　（17）尽可能地按照现实世界建模（我们常常为了遵守系统功能分布原则、避免全能类原则以及集中放置相关数据和行为的原则而违背这条原则） .（18）从你的设计中去除不需要的类。
　　一般来说，我们会把这个类降级成一个属性。
　　（19）去除系统外的类。
　　系统外的类的特点是，抽象地看它们只往系统领域发送消息但并不接受系统领域内其他类发出的消息。
　　（20）不要把操作变成类。质疑任何名字是动词或者派生自动词的类，特别是只有一个有意义行为的类。考虑一下那个有意义的行为是否应当迁移到已经存在或者尚未发现的某个类中。
　　（21）我们在创建应用程序的分析模型时常常引入代理类。在设计阶段，我们常会发现很多代理没有用的，应当去除。
　　（22）尽量减少类的协作者的数量。
　　一个类用到的其他类的数目应当尽量少。
　　（23）尽量减少类和协作者之间传递的消息的数量。
　　（24）尽量减少类和协作者之间的协作量，也即：减少类和协作者之间传递的不同消息的数量。
　　（25）尽量减少类的扇出，也即：减少类定义的消息数和发送的消息数的乘积。
　　（26）如果类包含另一个类的对象，那么包含类应当给被包含的对象发送消息。也即：包含关系总是意味着使用关系。
　　（27）类中定义的大多数方法都应当在大多数时间里使用大多数数据成员。
　　（28）类包含的对象数目不应当超过开发者短期记忆的容量。这个数目常常是6.当类包含多于6个数据成员时，可以把逻辑相关的数据成员划分为一组，然后用一个新的包含类去包含这一组成员。
　　（29）让系统功能在窄而深的继承体系中垂直分布。
　　（30）在实现语义约束时，最好根据类定义来实现。这常常会导致类泛滥成灾，在这种情况下，约束应当在类的行为中实现，通常是在构造函数中实现，但不是必须如此。
　　（31）在类的构造函数中实现语义约束时，把约束测试放在构造函数领域所允许的尽量深的包含层次中。
　　（32）Java面向对象中，约束所依赖的语义信息如果经常改变，那么最好放在一个集中式的第3方对象中。
　　（33）约束所依赖的语义信息如果很少改变，那么最好分布在约束所涉及的各个类中。
　　（34）类必须知道它包含什么，但是不能知道谁包含它。
　　（35）共享字面范围（也就是被同一个类所包含）的对象相互之间不应当有使用关系。
　　（36）继承只应被用来为特化层次结构建模。
　　（37）派生类必须知道基类，基类不应该知道关于它们的派生类的任何信息。
　　（38）基类中的所有数据都应当是私有的，不要使用保护数据。
　　类的设计者永远都不应该把类的使用者不需要的东西放在公有接口中。
　　（39）在理论上，继承层次体系应当深一点，越深越好。
　　（40）在实践中，继承层次体系的深度不应当超出一个普通人的短期记忆能力。一个广为接受的深度值是6.（41）所有的抽象类都应当是基类。
　　（42）所有的基类都应当是抽象类。
　　（43）把数据、行为和/或接口的共性尽可能地放到继承层次体系的高端。
　　（44）如果两个或更多个类共享公共数据（但没有公共行为），那么应当把公共数据放在一个类中，每个共享这个数据的类都包含这个类。
　　（45）如果两个或更多个类有共同的数据和行为（就是方法），那么这些类的每一个都应当从一个表示了这些数据和方法的公共基类继承。
　　（46）如果两个或更多个类共享公共接口（指的是消息，而不是方法），那么只有他们需要被多态地使用时，他们才应当从一个公共基类继承。
　　（47）对对象类型的显示的分情况分析一般是错误的。在大多数这样的情况下，设计者应当使用多态。
　　（48）对属性值的显示的分情况分析常常是错误的。类应当解耦合成一个继承层次结构，每个属性值都被变换成一个派生类。
　　（49）不要通过继承关系来为类的动态语义建模。试图用静态语义关系来为动态语义建模会导致在运行时切换类型。
　　（50）不要把类的对象变成派生类。对任何只有一个实例的派生类都要多加小心。
　　（51）如果你觉得需要在运行时刻创建新的类，那么退后一步以认清你要创建的是对象。现在，把这些对象概括成一个类。
　　（52）在派生类中用空方法（也就是什么也不做的方法）来覆写基类中的方法应当是非法的。
　　（53）不要把可选包含同对继承的需要相混淆。把可选包含建模成继承会带来泛滥成灾的类。
　　（54）在创建继承层次时，试着创建可复用的框架，而不是可复用的组件。
　　（55）如果你在设计中使用了多重继承，先假设你犯了错误。如果没犯错误，你需要设法证明。
　　（56）只要在Java面向对象设计中用到了继承，问自己两个问题：（1）派生类是否是它继承的那个东西的一个特殊类型？（2）基类是不是派生类的一部分？
　　（57）如果你在一个面向对象设计中发现了多重继承关系，确保没有哪个基类实际上是另一个基类的派生类。
　　（58）在面向对象设计中如果你需要在包含关系和关联关系间作出选择，请选择包含关系。
　　（59）不要把全局数据或全局函数用于类的对象的薄记工作。应当使用类变量或类方法。
　　（60）Java面向对象设计者不应当让物理设计准则来破坏他们的逻辑设计。但是，在对逻辑设计作出决策的过程中我们经常用到物理设计准则。
　　（61）不要绕开公共接口去修改对象的状态。 来源:考试大-Java认证