checked or runtime or unchecked?
"MalformedURL-
Exception, for instance, indicates that the address given for the service is not
valid. To recover from this exception, the application will at minimum need to be
reconfigured and may have to be recompiled. No try/catch block will be able to
recover gracefully, so why should your code be forced to catch and handle it?"
看SpringInAction时原RMI时,看到了上面的一段话,再结合这些天项目中的业务逻辑和异常处理,想通了异常处理时的一些困惑.
Java中的异常处理要比C++中强大的多(书上说的,这个我也能多多少少地体会的到),不过当初自学Java学到异常这一块很是苦恼,当时由于没有多少项目经验也就想体会不到Java里异常的优点.只是停留在字面上,"死盯"着"Exception"这个单词看,只是从它自己的类图里记住了Exception分RuntimeException和checked exception,根本不理解把Exception分成这几种情况的初衷,当然也不可能很好很自觉地用到自己的设计中来.
看到SpringInAction里的那段话后,再回过头来研读了Sun提供的Tutorial里关于"
The Three Kinds of Exceptions"(http://java.sun.com/docs/books/tutorial/essential/exceptions/catchOrDeclare.html)
的描述,现在一下子明白多了.
Exception这个单词说的就是正常业务逻辑之外的那想"不正常"(也就是"异"这个字的来源),不过这个"不正常"又可分成多种情况.
(1),用咱们的大白话有些不正常是用户自身造成的,就像SunTutorial里所说的那样,本来业务逻辑要求用户输入一个存在的可读的文件的路径给系统,可用户由于种种原因输入不合法,这种情况下,一个Well-written的系统就该报出Exception来告诉用户文件路径有误,并在用户重新输入路径后进入正常的处理逻辑.
(2),还有的不正常情况是那些用户和系统都无能为力的,比如说SunTutorial中提到的那种硬盘坏了.当这种"不正常"发生时用户很难像"文件不合法"那样就可以轻易就可解决掉的,针对这种情况,Java就提供了Error这个类.对于这个Error当然也可用Catch来捉住它,不过捉住后也没什么多大的用处(现在能想到一个好处就是把这个Error所描述的信息给更友好地报告给用户).
(3),上面的(1)和(2)都属于系统外部的(一个是用户自身,一个是硬件或网络情况),最后一种自然也就是系统自身了,像我们常看到的那种NullPointerException,NoSuchMethodException...这些异常的报出完全说明了系统自身不够robust,设计不够合理,Coding不够仔细.当这种Exception报出后,除了整个系统大修并重新编译外别的无药可救.这也就是"Runtime exceptions are not subject to the Catch or Specify Requirement. The application can catch this exception, but it probably makes more sense to eliminate the bug that caused the exception to occur."
现在再回过头来回答标题里的问题:我们所面对的"不正常"以check的角度来分有两种:checked和unchekced(呵呵,有些废话的意思).而unchecked分为Error和Exception里除RuntimeException中别的子类.
刚看到的一个新链接: http://www.javaworld.com/javaworld/jw-11-2007/jw-11-exceptionset.html