不好的一面包括两种情况：滥用不可检查异常（unchecked exceptions）和滥用catchall构造器等。这两种方式都使得问题变得复杂起来。

　　有一种类别的异常属于RuntimeException的子类，这种异常不会受到编译器的检查。比如，NullPointerException和 ArrayStoreException就是这种类型异常的实例。程序员可以对RuntimeException进行子类化以回避检查异常的限制，从而便于产生这些异常的方法为其调用者所使用。

　　专业的开发团队应当只允许在很少的情况下才可以这样做。

　　第二种异常处理的陋习是catchall构造器。所谓的“catchall 构造器”就是一种异常捕获代码模块，它可以处理所有扔给它的可能异常。

　　以下是catchall处理器的实例：

　　我得承认，我自己在编写一般程序的时候就曾经用过这种技术；但是，在编写关键程序的时候这种类型的构造器一定要避免使用，除非他们被授权可以和中央错误处理器联合使用才可以这样做。

　　除此之外，catchall构造器不过只是一种通过避免错误处理而加快编程进度的机制。

　　异常处理的一个不足之处是难以采用优良的错误处理策略。从低容内存状态恢复、写入错误和算法错误等异常情况都不是轻易能得到解决的。你可以尝试一下循环、垃圾收集和提醒用户等常用技术来应付以上的局面。

　　恶劣的处理方法

　　和许多Java特性及其API类似，Java的异常处理机制也有“霸王硬上弓”类的滑稽错误。比方说，为了扔出某个异常竟然毫不犹豫地用“new”关键词为其分配内存就是这样的例子。

　　我自己不知道有多少次就因为犯了这种错误而在严肃的编译器面前屡屡碰壁。在这种情况下，我们其实都是在伺候语言而不是让语言为我们所用。还有我们碰到的OutOfMemoryErrors就是异常处理的缺陷。这一处理过程是：

　　使用finally模块关闭文件，解析异常以得到出现问题的方法和代码行。在这一过程之内最大的缺陷是需要捕获OutOfMemoryError，而这一异常却并不是可检查异常！想想看，内存耗尽是相当常见的情况。任何与内存使用状态紧密相关的程序都应当捕获和处理这一错误。

　　使用异常时的一些建议

　　1．异常控制的设计宗旨并不是用来代替一些简单的测试。只有在异常情况下才使用异常！

　　2．不要过分细化异常。不要在每个语句上都加上异常处理，最好将整个任务都放在try块内。如果其中有一项操作失败，可以随即放弃任务。

　　3．不要“压制”异常。对于需要通告异常的方法，我们可以改用捕捉的方法来将异常强行关闭，如果真的出现异常，那个异常会被“静悄悄”的忽略。如果觉得产生的异常会非常重要，就必须多费些功夫，对其进行正确的控制。

　　4．不要介意异常的传递。如果调用的方法会产生异常，比如readLine方法，他们天生就能捕捉自己可能产生的异常，在这种情况下，一种更好地做法是将这些异常传递出去，而不是自己动手来捕捉它。

(编辑:aniston)