// code here with checked exceptions

 
　　}
　　

catch

 (Throwable t)

　　{
　　t.printStackTrace();
　　}
 
　　我得承认，我自己在编写一般程序的时候就曾经用过这种技术;但是，在编写关键程
序的时候这种类型的构造器一定要避免使用，除非他们被授权可以和中央错误处理器联
合使用才可以这样做。
　　除此之外，catchall 构造器不过只是一种通过避免错误处理而加快编程进度的机制。
　　异常处理的一个不足之处是难以采用优良的错误处理策略。从低容内存状态恢复、写
入错误和算法错误等异常情况都不是轻易能得到解决的。你可以尝试一下循环、垃圾收集
和提醒用户等常用技术来应付以上的局面。
　　恶劣的处理方法
　　和许多 Java 特性及其 API 类似，Java

“

”

的异常处理机制也有 霸王硬上弓 类的滑稽错

“

误。比方说，为了扔出某个异常竟然毫不犹豫地用

new

”关键词为其分配内存就是这样的

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

finally

模块关闭文件，解析异常以得到出现问题的方法和代码行。在这一过程之

内最大的缺陷是需要捕获 OutOfMemoryError，而这一异常却并不是可检查异常!想想看，
内存耗尽是相当常见的情况。任何与内存使用状态紧密相关的程序都应当捕获和处理这一
错误。
　　使用异常时的一些建议
　　

1

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

常!
　　

2

.不要过分细化异常。不要在每个语句上都加上异常处理，最好将整个任务都放在

try

块内。如果其中有一项操作失败，可以随即放弃任务。
　　

3

.

“

”

不要 压制 异常。对于需要通告异常的方法，我们可以改用捕捉的方法来将异常强

“

”

行关闭，如果真的出现异常，那个异常会被 静悄悄 的忽略。如果觉得产生的异常会非常
重要，就必须多费些功夫，对其进行正确的控制。
　　

4

.不要介意异常的传递。如果调用的方法会产生异常，比如 readLine 方法，他们天生

就能捕捉自己可能产生的异常，在这种情况下，一种更好地做法是将这些异常传递出去，
而不是自己动手来捕捉它。