文章结束给大家来个程序员笑话：[M]
异常的观点
任何的异常都是Throwable类（为何不是接口？？），并且在它之下包含两个字类Error / Exception，而Error仅在当在Java虚拟机中发生动态连接失败或其它的定位失败的时候，Java虚拟机抛出一个Error对象。典型的简易程序不捕获或抛出Errors对象，你可能永远不会碰到需要实例化Error的应用，那就让我们关心一下Exception。
Exception中比拟重要的就是RuntimeException（运行时异常）－可能在执行方法期间抛出但未被捕获的 RuntimeException 的任何子类都无需在 throws 子句中停止声明，也就是说你的应用应当不去“关心”（说不关心是不服义务的，但只是你不应当试图实例化它的字类）。 RuntimeException，就犹如你不应当关心Error的发生与处理一样！RuntimeException描述的是程序的错误引起来的，因该由程序累赘这个义务！（从义务这个角度看Error属于JVM需要累赘的义务;RuntimeException是程序应当累赘的义务;checked exception 是具体应用累赘的义务）
除了Error与RuntimeException，其他剩下的异常都是你需要关心的，而这些异常类统称为Checked Exception,至于Error与RuntimeException则被统称为Unchecked Exception.
关于 Java 中引入的 Checked Exceptions，目前存在着很多支持看法。正方的观念是引入 Checked Exceptions，可以增长程度的鲁棒性。反方的观念是 Checked Exceptions 很少被开发职员正确应用过，并且降低了程序开发的生产率和代码的执行效率。
Java 中定义了两类异常：
1) Checked exception: 这类异常都是Exception的子类 。异常的向上抛出机制停止处理，如果子类可能发生A异常，那么在父类中也必须throws A异常。可能致使的问题：代码效率低，耦合度太高。C#中就没有应用这类异常机制。
2) Unchecked exception: 这类异常都是RuntimeException的子类，虽然RuntimeException一样也是Exception的子类，但是它们是特别的，它们不能通过client code来试图解决，所以称为Unchecked exception 。
- 什么是unchecked异常?
即RuntimeException（运行时异常）
不需要try...catch...或throws 机制去处理的异常
- 列举最常用的五种RuntimeException:
这是JAVA认证测验中最常见的题目,事实上,runtime exception中最常见的,经常碰到的,也就5,6种,如下:
| ArithmeticException | int a=0; int b= 3/a; |
| ClassCastException： | Object x = new Integer(0); System.out.println((String)x); |
| IndexOutOfBoundsException ArrayIndexOutOfBoundsException, StringIndexOutOfBoundsException |
int [] numbers = { 1, 2, 3 }; int sum = numbers[3]; |
| IllegalArgumentException NumberFormatException |
int a = Interger.parseInt("test"); |
| NullPointerExceptionextends |
- 除了RuntimeException，其他继承自java.lang.Exception得异常统称为Checked Exception,他们有多少种呢?
下面是JDK API中列出的异常类:
除了RuntimeException以外的,都是checked Exception：
AclNotFoundException, ActivationException, AlreadyBoundException, ApplicationException, AWTException, BackingStoreException, BadAttributeValueExpException, BadBinaryOpValueExpException, BadLocationException, BadStringOperationException, BrokenBarrierException, CertificateException, ClassNotFoundException, CloneNotSupportedException, DataFormatException, DatatypeConfigurationException, DestroyFailedException, ExecutionException, ExpandVetoException, FontFormatException, GeneralSecurityException, GSSException, IllegalAccessException, IllegalClassFormatException, InstantiationException, InterruptedException, IntrospectionException, InvalidApplicationException, InvalidMidiDataException, InvalidPreferencesFormatException, InvalidTargetObjectTypeException, InvocationTargetException, IOException, JAXBException, JMException, KeySelectorException, LastOwnerException, LineUnavailableException, MarshalException, MidiUnavailableException, MimeTypeParseException, MimeTypeParseException, NamingException, NoninvertibleTransformException, NoSuchFieldException, NoSuchMethodException, NotBoundException, NotOwnerException, ParseException, ParserConfigurationException, PrinterException, PrintException, PrivilegedActionException, PropertyVetoException, RefreshFailedException, RemarshalException, RuntimeException, SAXException, ScriptException, ServerNotActiveException, SOAPException, SQLException, TimeoutException, TooManyListenersException, TransformerException, TransformException, UnmodifiableClassException, UnsupportedAudioFileException, UnsupportedCallbackException, UnsupportedFlavorException, UnsupportedLookAndFeelException, URIReferenceException, URISyntaxException, UserException, XAException, XMLParseException, XMLSignatureException, XMLStreamException, XPathException
Java 中定义了两类异常：
1) Checked exception: 这类异常都是Exception的子类 。异常的向上抛出机制停止处理，如果子类可能发生A异常，那么在父类中也必须throws A异常。可能致使的问题：代码效率低，耦合度太高。C#中就没有应用这类异常机制。
2) Unchecked exception: 这类异常都是RuntimeException的子类，虽然RuntimeException一样也是Exception的子类，但是它们是特别的，它们不能通过client code来试图解决，所以称为Unchecked exception 。
checked exception是需要强制catch的异常，你在调用这个方法的时候，你如果不catch这个异常，那么编译器就会报错，比如说我们读写文件的时候会catch IOException，执行数据库操纵会有SQLException等
UnChecked Exception是RuntimeException，也就是说运行时的异常，这类异常不是必须需要catch的，你是没法预料的，比如说你在调用一个list.szie()的时候，如果这个list为null，那么就会报NUllPointerException，而这个异常就是RuntimeException，也就是UnChecked Exception
Error和RuntimeException及其子类是unchecked exception.其他exception是checked exception.
checked exception可以出现在throws子句中，unchecked exception不可以。
Error是java自己的错误或者诸如内存耗尽等严重错误，是不可抗拒的，显然没有捕捉的须要，而且也没有方法捕捉。
RuntimeException是你的程序有逻辑错误，是程序员应当积极避免其出现的异常。比如NullPointerException等，完全是程序员马虎出的错。当碰到这类错误时，java将这个错误主动捕捉到，比如表现到concole里，然后继续运行。而checked exception如果不捕捉则会致使程序终止。
error 表示恢复不是不可能但很难题的情况下的一种严重问题。比如说内存溢出。不可能期望程序能处理这样的情况。
exception 表示一种计划或实现问题。也就是说，它表示如果程序运行畸形，从不会发生的情况
error和excption的区分
Error的继承关系：
java.lang.Object
--java.lang.Throwable
--java.lang.Error
Exception的继承关系：
java.lang.Object
--java.lang.Throwable
--java.lang.Exception
两者的不同之处：
Exception：
1．可以是可被控制(checked) 或不可控制的(unchecked)
2．表示一个由程序员致使的错误
3．应当在应用程序级被处理
Error：
1．总是不可控制的(unchecked)
2．经常用来用于表示系统错误或低层资源的错误
3．如何可能的话，应当在系统级被捕捉
一、常见异常的类型与原因。
对于Java应用程序的常见异常，笔者认为程序开发职员要从两个方面去了解。一是要晓得有哪些常见的Java应用程序异常，二是需要晓得哪些原因可能会造成这个异常。这不仅需要程序管理职员在平常工作中要注意积聚，在须要的情况下还需要去从其它渠道收集资料。笔者对此就停止一个分析，希望可以对各位程序开发职员有必定的帮助。
1、 SQLException：操纵数据库异常类。
现在的Java应用程序大部分都是依赖于数据库运行的。当Java应用程序与数据库停止相同时如果发生了错误，就会触发这个类。同时会将数据库的错误信息通过这个类表现给用户。也就是说，这个操纵数据库异常类是数据库与用户之间异常信息传递的桥梁。如现在用户往系统中插入数据，而在数据库中规定某个字段必须唯一。当用户插入数据的时候，如果这个字段的值跟现有的记录重复了，违反了数据库的唯一性约束，此时数据库就会跑出一个异常信息。这个信息一般用户可能看不到，因为其发生在数据库层面的。此时这个操纵数据库异常类就会捕捉到数据库的这个异常信息，并将这个异常信息传递到前台。如此的话，前台用户就可以根据这个异常信息来分析发生错误的原因。这就是这个操纵数据库异常类的主要用途。在Java应用程序中，全部数据库操纵发生异常时，都市触发这一个类。全部此时Java应用程序本身的提示信息往往过于笼统，只是说与数据库交互出现错误，没有多大的参考价值。此时反而是数据库的提示信息更加有应用价值。
2、 ClassCastException：数据类型转换异常。
在Java应用程序中，有时候需要对数据类型停止转换。这个转换包含表现的转换与隐式的转换。不过无论怎么转换，都必须要符合一个前提的条件，即数据类型的兼容性。如果在数据转换的过程中，违反了这个原则，那么就会触发数据类型转换异常。如现在在应用程序中，开发职员需要将一个字符型的日期数据转换为数据库所可以接受的日期型数据，此时只要要在前台应用程序中停止控制，一般不会有问题。但是，如果前台应用程序缺乏相干的控制，如用户在输入日期的时候只输入月、日信息，而没有年份的信息。此时应用程序在停止数据类型转换的时候，就会出现异常。根据笔者的经验，数据类型转换异常在应用程序开发中使一个出现的比拟多的异常，也是一个比拟低级的异常。因为大部分情况下，都可以在应用程序窗口中对数据类型停止一些强制的控制。即在数据类型停止转换之前，就保证数据类型的兼容性。如此的话，就不轻易造成数据类型的转换异常。如在只允许数值类型的字段中，可以设置不允许用户输入数值以外的字符。虽然说有了异常处理机制，可以保证应用程序不会被错误的运行。但是在实际开发中，还是要尽可能多的预感错误发生的原因，尽量避免异常的发生。
3、 NumberFormatException：字符串转换为数字类型时抛出的异常。
在数据类型转换过程中，如果是字符型转换为数字型过程中出现的问题，对于这个异常在Java程序中采用了一个独立的异常，即NumberFormatException.如现在讲字符型的数据“123456”转换为数值型数据时，是允许的。但是如果字符型数据中包含了非数字型的字符，如123#56，此时转换为数值型时就会出现异常。系统就会捕捉到这个异常，并停止处理。
Java应用程序中常见的异常类还有很多。如未找到相应类异常、不允许访问某些类异常、文件已经结束异常、文件未找到异常、字段未找到异常等等。一般系统开发职员都可以根据这个异常名来判断当前异常的类型。虽然不错，但是好忘性不如烂笔头。程序开发职员在须要的时候（特别是存在自定义异常的时候），最后手头有一份异常明细表。如此的话，无论是应用程序在调试过程中发明问题，还是运行过程中接到用户的投诉，都可以及时的根据异常名字来找到异常发生的原因。从而可以在最短时间内解决异常，恢复应用程序的畸形运行。这个措施笔者用了很多年，非常的有效。
二、异常管理的实用提议。
对于操纵数据库异常来说，Java应用程序只供给了一个异常类。故光凭Java应用程序的错误信息，往往不可以帮助应用程序职员排除错误的原因。只可以指名是应用程序错误还是数据库错误致使的这个异常。为了更进一步指明问题的原因，在数据库层面定义异常的时候，最好可以说明具体的原因。如前台应用程序可能会调用数据库的函数或者过程。此时在数据库的函数或者过程中做好可以说明某个异常的具体原因。如根据某个基础表生成另一张表的时候，某个字段不可认为空等等。将这些异常信息说明清晰后，如果真的碰到类似的异常时，操纵数据库异常类就会将数据库的异常信息反会给前台用户。从而有利于用户寻觅问题的原因，并在最短时间内改正。当然，这需要Java程序员与数据库计划职员停止协调。
其次需要注意的是，异常并非常态。也就是说，大部分异常可以通过前提的公道预感与防备，来消除。如计划到四则运算，可以在前台应用程序窗口中限制在除数字段内输入0值等手段来消除应用程序运行中可能发生的异常。不过这往往要求应用程序开发职员有比拟丰硕的工作经验以及由比拟周密的思维逻辑。虽然这有必定的难度，但是笔者认为程序开发职员还是应当往这方面努力，而不要老是让用户作为你的试验品，让用户来发明应用程序中的计划Bug.笔者认为，只有一些实在是程序职员没法控制的要素才允许抛出异常。如果应用程序开发职员可以意想到这类错误、但是仍然没有引起重视或者采用有效的措施避免出现这类异常，那么笔者是不允许的。
ArithmeticException（除数为0的异常）, BufferOverflowException（缓冲区上溢异常）, BufferUnderflowException（缓冲区下溢异常）, IndexOutOfBoundsException（出界异常）, NullPointerException（空指针异常）, EmptyStackException（空栈异常）, IllegalArgumentException（不合法的参数异常）, NegativeArraySizeException, NoSuchElementException, SecurityException, SystemException, UndeclaredThrowableException
1. java.lang.NullPointerException
异常的解释是"程序遇上了空指针"，简略地说就是调用了未经初始化的对象或者是不存在的对象，即把数组的初始化和数组元素的初始化混杂起来了。数组的初始化是对数组分配需要的空间，而初始化后的数组，其中的元素并没有实例化，依然是空的，所以还需要对每个元素都停止初始化（如果要调用的话）
2. java.lang.ClassNotFoundException 异常的解释是"指定的类不存在"。
3. java.lang.ArithmeticException 这个异常的解释是"数学运算异常"，比如程序中出现了除以零这样的运算就会出这样的异常。
4. java.lang.ArrayIndexOutOfBoundsException
异常的解释是"数组下标越界"，现在程序中大多都有对数组的操纵，因此在调用数组的时候必定要当真检查，看自己调用的下标是否是超出了数组的范围，一般来说，表现（即直接用常数当下标）调用不太轻易出这样的错，但隐式（即用变量表示下标）调用就经常出错了，还有一种情况，是程序中定义的数组的长度是通过某些特定方法决议的，不是事前声明的，这个时候，最好先查看一下数组的length，以免出现这个异常。
5. java.lang.IllegalArgumentException
这个异常的解释是"方法的参数错误"，比如g.setColor(int red,int green,int blue)这个方法中的三个值，如果有超越２５５的也会出现这个异常，因此一旦发明这个异常，我们要做的，就是赶忙去检查一下方法调用中的参数传递是否是出现了错误。
6. java.lang.IllegalAccessException
这个异常的解释是"没有访问权限"，当应用程序要调用一个类，但当前的方法即没有对该类的访问权限便会出现这个异常。对程序中用了Package的情况下要注意这个异常
一．异常介绍
任何的异常都是Throwable类，并且在它之下包含两个字类Error / Exception，而Error仅在当在Java虚拟机中发生动态连接失败或其它的定位失败的时候，Java虚拟机抛出一个Error对象。典型的简易程序不捕捉或抛出Errors对象，你可能永远不会碰到需要实例化Error的应用，那就让我们关心一下Exception。
Unchecked Exception.：包含 Error与RuntimeException. 这类异常都是RuntimeException的子类。
Checked Exception:除了Error与RuntimeException，其他剩下的异常. 这类异常都是Exception的子类 。在编译时在语法上必须处理的异常，因此必须在语法上以try..catch加以处理；
二．计划异常的最佳实践 （Best Practises for Designing the API）
1． 当要决议是采用checked exception还是Unchecked exception的时候，你要问自己一个问题，“如果这类异常一旦抛出，客户端会做怎样的弥补？”
[原文：When deciding on checked exceptions vs. unchecked exceptions, ask yourself, "What action can the client code take when the exception occurs?"]
如果客户端可以通过其他的方法恢复异常，那么这类异常就是checked exception；如果客户端对出现的这类异常力所不及，那么这类异常就是Unchecked exception；从应用上讲，当异常出现的时候要做一些试图恢复它的动作而不要仅仅的打印它的信息，总来的来说，看下表：
|
Client's reaction when exception happens |
Exception type |
|
Client code cannot do anything |
Make it an unchecked exception |
|
Client code will take some useful recovery action based on information in exception |
Make it a checked exception |
此外，尽量应用unchecked exception来处理编程错误：因为unchecked exception不用使客户端代码表现的处理它们，它们自己会在出现的地方挂起程序并打印出异常信息。Java API中供给了丰硕的unchecked excetpion，譬如：NullPointerException , IllegalArgumentException 和 IllegalStateException等，因此我一般应用这些标准的异常类而不肯亲自创立新的异常类，这样使我的代码易于理解并避免的过多的消耗内存。
2． 掩护封装性（Preserve encapsulation）
不要让你要抛出的checked exception升级到较高的层次。例如，不要让SQLException延伸到业务层。业务层并不需要（不关心？）SQLException。你有两种方法来解决这类问题：
l 转变SQLException为另外一个checked exception，如果客户端并不需要恢复这类异常的话；
l 转变SQLException为一个unchecked exception，如果客户端对这类异常力所不及的话；
多数情况下，客户端代码都是对SQLException力所不及的，因此你要毫不犹豫的把它转变为一个unchecked exception，看看下边的代码：
|
public void dataAccessCode(){ try{ ..some code that throws SQLException }catch(SQLException ex){ ex.printStacktrace(); } } |
上边的catch块牢牢打印异常信息而没有任何的直接操纵，这是无可非议的，因为对于SQLException你还奢望客户端做些什么呢？（但是显然这类就象什么事情都没发生一样的做法是不可取的）那么有无另外一种更加可行的方法呢？
|
public void dataAccessCode(){ try{ ..some code that throws SQLException }catch(SQLException ex){ throw new RuntimeException(ex); } } |
上边的做法是把SQLException转换为RuntimeException，一旦SQLException被抛出，那么程序将抛出RuntimeException,此时程序被挂起并返回客户端异常信息。
如果你有足够的信念恢复它当SQLException被抛出的时候，那么你也可以把它转换为一个有意思的checked exception, 但是我发明在大多时候抛出RuntimeException已经足够用了。
3． 不要创立没有意思的异常（Try not to create new custom exceptions if they do not have useful information for client code.）
看看下面的代码有什么问题？
|
public class DuplicateUsernameException extends Exception {} |
它除了有一个“意思明白”的名字以外没有任何有效的信息了。不要忘记Exception跟其他的Java类一样，客户端可以调用其中的方法来失掉更多的信息。
我们可认为其添加一些须要的方法，如下：
|
public class DuplicateUsernameException extends Exception { public DuplicateUsernameException (String username){....} public String requestedUsername(){...} public String[] availableNames(){...} } |
在新的代码中有两个有效的方法：reqeuestedUsername(),客户但可以通过它失掉请求的名称；availableNames(),客户端可以通过它失掉一组有效的usernames。这样客户端在失掉其返回的信息来明白自己的操纵失败的原因。但是如果你不想添加更多的信息，那么你可以抛出一个标准的Exception:
|
throw new Exception("Username already taken"); |
愈甚的情况，如果你认为客户端并不想用过多的操纵而仅仅想看到异常信息，你可以抛出一个unchecked exception:
|
throw new RuntimeException("Username already taken"); |
另外，你可以供给一个方法来验证该username是否被占用。
很有须要再重申一下，checked exception应当让客户端从中失掉丰硕的信息。要想让你的代码更加易读，请倾向于用unchecked excetpion来处理程序中的错误（Prefer unchecked exceptions for all programmatic errors）。
4． Document exceptions.
你可以通过Javadoc’s @throws 标签来说明（document）你的API中要抛出checked exception或者unchecked exception。然而，我更倾向于应用来单元测试来说明（document）异常。不管你采用哪中方式，你要让客户端代码晓得你的API中所要抛出的异常。这里有一个用单元测试来测试IndexOutOfBoundsException的例子：
|
public void testIndexOutOfBoundsException() { ArrayList blankList = new ArrayList(); try { blankList.get(10); fail("Should raise an IndexOutOfBoundsException"); } catch (IndexOutOfBoundsException success) {} }
|
上边的代码在请求blankList.get(10)的时候会抛出IndexOutOfBoundsException,如果没有被抛出，将fail("Should raise an IndexOutOfBoundsException")表现说明该测试失败。通过誊写测试异常的单元测试，你不但可以看到异常是怎样的工作的，而且你可以让你的代码变得越来越硬朗。
三．应用异常的最佳实践（Best Practices for Using Exceptions）
1． 总是要做一些清理工作（Always clean up after yourself）
如果你应用一些资源例如数据库连接或者网络连接，请记着要做一些清理工作（如关闭数据库连接或者网络连接），如果你的API抛出Unchecked exception，那么你要用try-finally来做须要的清理工作：
|
public void dataAccessCode(){ Connection conn = null; try{ conn = getConnection(); ..some code that throws SQLException }catch(SQLException ex){ ex.printStacktrace(); } finally{ DBUtil.closeConnection(conn); } } class DBUtil{ public static void closeConnection (Connection conn){ try{ conn.close(); } catch(SQLException ex){ logger.error("Cannot close connection"); throw new RuntimeException(ex); } } } |
DBUtil是一个工具类来关闭Connection.有须要的说的应用的finally的重要性是不管程序是否碰到异常，它都市被执行。在上边的例子中，finally中关闭连接，如果在关闭连接的时候出现错误就抛出RuntimeException.
2． 不要应用异常来控制流程（Never use exceptions for flow control）
下边代码中，MaximumCountReachedException被用于控制流程：
|
public void useExceptionsForFlowControl() { try { while (true) { increaseCount(); } } catch (MaximumCountReachedException ex) { } //Continue execution }
public void increaseCount() throws MaximumCountReachedException { if (count >= 5000) throw new MaximumCountReachedException(); } |
上边的useExceptionsForFlowControl()用一个无限循环来增长count直到抛出异常，这类做法并没有说让代码不容易读，但是它是程序执行效率降低。
记着，只在要会抛出异常的地方停止异常处理。
3． 不要忽略异常
当有异常被抛出的时候，如果你不想恢复它，那么你要毫不犹豫的将其转换为unchecked exception，而不是用一个空的catch块或者什么也不做来忽略它，以至于从表面来看象是什么也没有发生一样。
4． 不要捕获顶层的Exception
unchecked exception都是RuntimeException的子类，RuntimeException又继承Exception,因此，如果单纯的捕获Exception,那么你一样也捕获了RuntimeException,如下代码：
|
try{ .. }catch(Exception ex){ } |
一旦你写出了上边的代码（注意catch块是空的），它将忽略全部的异常，包含unchecked exception.
5． Log exceptions just once
Logging the same exception stack trace more than once can confuse the programmer examining the stack trace about the original source of exception. So just log it once.
总结
这里给出了一些关于异常处理的一些最佳实践，我并不想开始另一轮的关于checked exception 和 unchecked exception的争论。你可以根据自己的实际情况定制自己异常处理，我坚信我们将有更好的方法来处理我们代码中的异常。
文章结束给大家分享下程序员的一些笑话语录：
刹车失灵
有一个物理学家，工程师和一个程序员驾驶着一辆汽车行驶在阿尔卑斯山脉 上，在下山的时候，忽然，汽车的刹车失灵了，汽车无法控制地向下冲去， 眼看前面就是一个悬崖峭壁，但是很幸运的是在这个悬崖的前面有一些小树 让他们的汽车停了下来， 而没有掉下山去。 三个惊魂未定地从车里爬了出来。
物理学家说， “我觉得我们应该建立一个模型来模拟在下山过程中刹车片在高 温情况下失灵的情形”。
工程师说， “我在车的后备厢来有个扳手， 要不我们把车拆开看看到底是什么 原因”。
程序员说，“为什么我们不找个相同的车再来一次以重现这个问题呢？”
---------------------------------
原创文章 By
异常和exception
---------------------------------