java了解异常_ID检测,java异常处理

只针对不正常的条件才使用异常

异常只应该被用于不正常的条件，它们永远不应被用于正常的控制流。

下面是一个用异常作遍历结束条件的滥用异常的例子：

//horrible abuse of exceptions. Don't ever do this!

try{

int i=0;

while(true)a[i++].f();

}catch(ArrayIndexOutOfBoundsException e){

...

}

其错有三：

1、创建、抛出和捕获异常的开销是很昂贵的。因为它的初衷是用于不正常的情形，少有jvm会它进行性能优化。

2、把代码放在try-catch中会阻止jvm实现本来可能要执行的某些特定的优化。

3、有些现代的jvm对循环进行优化，不会出现冗余的检查。

完全可以使用标准的实现方式：

for(int i=0;i

a[i].f();

}

这条原则也适用于API设计。一个设计良好的API不应该强迫它的客户为了正常的控制流而使用异常。如果类中有一个”状态相关”的方法，即只有特定的条件下可被调用的方法，则这个类也应有一个单独的“状态测试”方法，以为调用这个状态相关方法前的检查。如Collection类的next方法和 hasNext方法。

for(Iterator i=collection.iterator();i.hasNext();){

Foo foo=(Foo)i.next();

...

}

对于可恢复的条件使用被检查的异常，对于程序错误使用运行时异常

java提供了三种可抛出的异常：被检查的异常(checkedException)、运行时异常(run-time Exception)和错误(error)。　　如果期望调用者在调用时出现的异常能够恢复，则应该使用被检查的异常，通过抛出一个被检查的异常，强迫调用者在catch中处理该异常，或者将异常传播到外面。

对于一个方法声明要抛出的每一个被检查的异常，它是对API用户的一种潜在指示：与异常相关联的条件是调用这次个方法的一种可能结果。

两种未被检查的可抛出结构：运行时异常和错误，在行为上相同的，它们都不需要、也不应该被捕获的抛出物。你所实现的所有未被检查的抛出结构都应是 RuntimeException的子类。定义一个非Exception、RuntimeException或Error子类的抛出物是可行的，但从行为意义上它等同于被普通的被检查异常(即Exception子类而非RuntimeException子类).

避免不必要地使用被检查的异常

与返回代码不同，被检查的异常强迫程序处理例外的情况，从而大大地提高了程序的可靠性。而过分地使用被检查的异常