在编程时，开发人员常常会遭遇各式各样莫名错误。
近日，Sushil Das在 Geek On Java上列举了 Java 开发中常见的 5 个错误，与君共「免」。
1、Null 的过度使用
避免过度使用 null 值是一个最佳实践。
比如，更好的做法是让方法返回空的 array 或者 collection 而不是 null 值，由于这样能够防止程序抛出 NullPointerException。
以下代码片段会从还有一个方法获得一个集合：
List<String> accountIds = person.getAccountIds();
for (String accountId : accountIds) {
processAccount(accountId);
}
当一个 person 没有 account 的时候。getAccountIds() 将返回 null 值，程序就会抛出 NullPointerException 异常。因此须要增加空检查来解决问题。
假设将返回的 null 值替换成一个空的 list，那么 NullPointerException 也不会出现。并且，由于我们不再须要对变量 accountId 做空检查，代码将变得更加简洁。
当你想避免 null 值的时候，不同场景可能採取不同做法。当中一个方法就是使用 Optional 类型。它既能够是一个空对象。也能够是一些值的封装。
Optional<String> optionalString = Optional.ofNullable(nullableString);
if(optionalString.isPresent()) {
System.out.println(optionalString.get());
}
其实，Java8 提供了一个更简洁的方法：
Optional<String> optionalString = Optional.ofNullable(nullableString); optionalString.ifPresent(System.out::println);
Java 是从 Java8 版本号開始支持 Optional 类型，可是它在函数式编程世界早已广为人知。在此之前，它已经在 Google Guava 中针对 Java 的早期版本号被使用。
2、忽视异常
我们常常对异常置之不理。然而，针对刚開始学习的人和有经验的 Java 程序猿，最佳实践仍是处理它们。异常抛出一般是带有目的性的。因此在大多数情况下须要记录引起异常的事件。别小看这件事，假设必要的话，你能够又一次抛出它，在一个对话框中将错误信息展示给用户或者将错误信息记录在日志中。至少，为了让其他开发人员知晓前因后果，你应该解释为什么没有处理这个异常。
selfie = person.shootASelfie();
try {
selfie.show();
} catch (NullPointerException e) {
// Maybe, invisible man. Who cares, anyway?
}
强调某个异常不重要的一个简便途径就是将此信息作为异常的变量名，像这样：
try { selfie.delete(); } catch (NullPointerException unimportant) { }
3、并发改动异常
这样的异常发生在集合对象被改动，同一时候又没有使用 iterator 对象提供的方法去更新集合中的内容。比如。这里有一个 hats 列表，并想删除当中全部含 ear flaps 的值：
List<IHat> hats = new ArrayList<>();
hats.add(new Ushanka()); // that one has ear flaps
hats.add(new Fedora());
hats.add(new Sombrero());
for (IHat hat : hats) {
if (hat.hasEarFlaps()) {
hats.remove(hat);
}
}
假设执行此代码，ConcurrentModificationException 将会被抛出，由于代码在遍历这个集合的同一时候对其进行改动。当多个进程作用于同一列表，在当中一个进程遍历列表时，还有一个进程试图改动列表内容。相同的异常也可能会出现。
在多线程中并发改动集合内容是很常见的。因此须要使用并发编程中经常使用的方法进行处理。比如同步锁、对于并发改动採用特殊的集合等等。
Java 在单线程和多线程情况下解决问题有微小的区别。
收集对象并在还有一个循环中删除它们
直接的解决方式是将带有 ear flaps 的 hats 放进一个 list，之后用还有一个循环删除它。只是这须要一个额外的集合来存放将要被删除的 hats。
List<IHat> hatsToRemove = new LinkedList<>();
for (IHat hat : hats) {
if (hat.hasEarFlaps()) {
hatsToRemove.add(hat);
}
}
for (IHat hat : hatsToRemove) {
hats.remove(hat);
}
使用Iterator.remove方法
这种方法更简单，同一时候并不须要创建额外的集合：
Iterator<IHat> hatIterator = hats.iterator();
while (hatIterator.hasNext()) {
IHat hat = hatIterator.next();
if (hat.hasEarFlaps()) {
hatIterator.remove();
}
}
使用ListIterator的方法
当须要改动的集合实现了 List 接口时。list iterator 是非常合适的选择。实现 ListIterator 接口的 iterator 不仅支持删除操作，还支持add和set操作。ListIterator 接口实现了 Iterator 接口。因此这个样例看起来和Iterator的remove方法非常像。
唯一的差别是 hat iterator 的类型和我们获得 iterator 的方式——使用listIterator()方法。
以下的片段展示了怎样使用 ListIterator.remove和ListIterator.add方法将带有 ear flaps 的 hat 替换成带有sombreros 的。
IHat sombrero = new Sombrero();
ListIterator<IHat> hatIterator = hats.listIterator();
while (hatIterator.hasNext()) {
IHat hat = hatIterator.next();
if (hat.hasEarFlaps()) {
hatIterator.remove();
hatIterator.add(sombrero);
}
}
使用 ListIterator，调用remove和add方法可替换为仅仅调用一个set方法：
IHat sombrero = new Sombrero();
ListIterator<IHat> hatIterator = hats.listIterator();
while (hatIterator.hasNext()) {
IHat hat = hatIterator.next();
if (hat.hasEarFlaps()) {
hatIterator.set(sombrero); // set instead of remove and add
}
}
使用Java 8中的stream方法
在 Java8 中。开发者能够将一个 collection 转换为 stream。而且依据一些条件过滤 stream。
这个样例讲述了 stream api 是怎样过滤 hats 和避免ConcurrentModificationException。 hats = hats.stream().filter((hat -> !hat.hasEarFlaps()))
.collect(Collectors.toCollection(ArrayList::new));
Collectors.toCollection方法将会创建一个新的 ArrayList，它负责存放被过滤掉的 hats 值。假设过滤条件过滤掉了大量条目，这里将会产生一个非常大的 ArrayList。因此。须要慎重使用。
使用 Java 8 中的List.removeIf 方法
能够使用 Java 8 中还有一个更简洁明了的方法—— removeIf方法:
hats.removeIf(IHat::hasEarFlaps);
在底层，它使用 Iterator.remove来完毕这个操作。
使用特殊的集合
假设在一開始就决定使用CopyOnWriteArrayList而不是ArrayList，那就不会出现故障。
由于 CopyOnWriteArrayList提供了改动的方法（比如 set，add。remove），它不会去改变原始集合数组，而是创建了一个新的改动版本号。
这就同意遍历原来版本号集合的同一时候进行改动，从而不会抛出 ConcurrentModificationException异常。这样的集合的缺点也很明显——针对每次改动都产生一个新的集合。
还有其它适用于不同场景的集合。比方 CopyOnWriteSet和ConcurrentHashMap。
关于还有一个可能可能在并发改动集合时产生的错误是，从一个 collection 创建了一个 stream，在遍历 stream 的时候，同一时候改动后端的 collection。
针对 stream 的一般准则是，在查询 stream 的时候，避免改动后端的 collection。接下来的样例将展示怎样正确地处理 stream：
List<IHat> filteredHats = hats.stream().peek(hat -> {
if (hat.hasEarFlaps()) {
hats.remove(hat);
}
}).collect(Collectors.toCollection(ArrayList::new));
peek方法收集全部的元素。并对每个元素运行既定动作。在这里。动作即为尝试从一个基础列表中删除数据，这显然是错误的。为避免这种操作，能够尝试一些上面解说的方法。
4、违约
有时候，为了更好地协作。由标准库或者第三方提供的代码必须遵守共同的依赖准则。比如。必须遵守 hashCode和equals的共同约定，从而保证 Java 集合框架中的一系列集合类和其他使用hashCode和equals方法的类可以正常工作。
不遵守约定并不会产生 exception 或者破坏代码编译之类的错误；它非常阴险。由于它随时可能在毫无危急提示的情况下更改应用程序行为。
错误代码可能潜入生产环境，从而造成一大堆不良影响。这包含较差的 UI 体验、错误的数据报告、较差的应用性能、数据丢失或者很多其它。
庆幸的是。这些灾难性的错误不会常常发生。在之前已经提及了 hashCode 和equals 约定，它出现的场景可能是：集合依赖于将对象进行哈希或者比較。就像 HashMap 和 HashSet。
简单来说，这个约定有两个准则：
- 假设两个对象相等，那么 hash code 必须相等。
- 假设两个对象有同样的 hash code。那么它们可能相等也可能不相等。
破坏约定的第一条准则。当你试图从一个 hashmap 中检索数据的时候将会导致错误。第二个准则意味着拥有同样hash code的对象不一定相等。
以下看一下破坏第一条准则的后果：
public static class Boat {
private String name;
Boat(String name) {
this.name = name;
}
@Override
public boolean equals(Object o) {
if (this == o) return true;
if (o == null || getClass() != o.getClass()) return false;
Boat boat = (Boat) o;
return !(name != null ? !name.equals(boat.name) : boat.name != null);
}
@Override
public int hashCode() {
return (int) (Math.random() * 5000);
}
}
正如你所见，Boat 类重写了equals和hashCode方法。然而，它破坏了约定，由于 hashCode 针对每次调用的同样对象返回了随机值。以下的代码非常可能在 hashset 中找不到一个名为Enterprise的boat，虽然其实我们提前增加了这样的类型的 boat：
public static void main(String[] args) {
Set<Boat> boats = new HashSet<>();
boats.add(new Boat("Enterprise"));
System.out.printf("We have a boat named 'Enterprise' : %b/n", boats.contains(new Boat("Enterprise")));
}
还有一个约定的样例是finalize 方法。
这里是官方 Java 文档关于它功能描写叙述的引用：
finalize的常规约定是：当 JavaTM 虚拟机确定不论什么线程都无法再通过不论什么方式訪问指定对象时。这种方法会被调用，此后这个对象仅仅能在某个其它（准备终止的）对象或类终结时被作为某个行为的结果。finalize方法有多个功能，当中包含再次使此对象对其它线程可用；只是finalize的主要目的是在不可撤消地丢弃对象之前运行清除操作。比如，表示输入/输出连接对象的finalize方法可运行显式 I/O 事务，以便在永久丢弃对象之前中断连接。
你能够决定在诸如文件处理器中使用finalize方法来释放资源，可是这样的使用方法是非常糟糕的。因为它是在垃圾回收期间被调用的，而 GC 的时间并不确定，因此finalize被调用的时间将无法保证。
5、使用原始类型而不是參数化的
依据 Java 文档描写叙述：原始类型要么是非參数化的，要么是类 R 的（同一时候也是非继承 R 父类或者父接口的）非静态成员。在 Java 泛型被引入之前，并没有原始类型的替代类型。Java 从1.5版本号開始支持泛型编程。毫无疑问这是一个重要的功能提升。然而，因为向后兼容的原因，这里存在一个陷阱可能会破坏整个类型系统。着眼下例：
List listOfNumbers = new ArrayList();
listOfNumbers.add(10);
listOfNumbers.add("Twenty");
listOfNumbers.forEach(n -> System.out.println((int) n * 2));
这是一个由数字组成的列表被定义为原始的 ArrayList。因为它并没有指定类型參数。因此能够给它加入不论什么对象。
可是最后一行将其包括的元素映射为 int 类型并乘以 2，打印出翻倍之后的数据到标准输出。
此代码编译时不会出错，可是一旦执行就会抛出执行时错误，由于这里试图将字符类型映射为整形。
非常显然，假设隐藏了必要信息，类型系统将不能帮助写出安全代码。
为了解决问题。须要为存入集合中的对象指定详细类型：
List<Integer> listOfNumbers = new ArrayList<>();
listOfNumbers.add(10);
listOfNumbers.add("Twenty");
listOfNumbers.forEach(n -> System.out.println((int) n * 2));
与之前代码的唯一区别即是定义集合的那一行：
List<Integer> listOfNumbers = new ArrayList<>();
改动之后的代码编译不可能被通过。由于这里试图向仅仅期望存储整形的集合中加入字符串。编译器将会显示错误信息，并指向试图向列表中加入Twenty字符的那一行。參数化泛型类型是个不错的主意。这种话，编译器就行检查全部可能的类型，从而由于类型不一致而导致的执行时异常几率将大大减少。
本文来源：码农网