处理异常有两种基本的方式：在程序内部捕获它并处理
try{}
catch(){}
或者：在方法的异常规范中声明，告诉上一层的程序，本代码会掷出异常，请处理
throws Exception{}
但是，怎么样选择这两种方法呢？
我看了一下thinking in java 3rd
里面有一段关于处理方法的选择的话附于后：
我觉得可以理解下面一些原则：
１、目的：把处理异常的部分和功能部分分开，使系统易于理解和维护；
２、原则：你如果不知道怎么处理一个异常就不要捕获它（而把它交给上级处理）；
３、但是具体的处理方式仍是灵活多变的，In this section we’ll look at some of the issues and complications arising from checked exceptions, and options that you have when dealing with them.
所以，我现在只有在利用原则２的情况下使代码尽可能的简单。
４、最后那段话不大明白，好像是说从原来Ｃ风格的异常处理转过来的人会感到有很大的利益的改变，但是作者感到当它使用起来不大方便的时候又有点迷惑了。最后写了一句什么：“所以的模型都是错的，一些是有用的”。是什么意思？世上没有十全十美的方法吗？
Alternative approaches
An exception-handling system is a trap door that allows your program to abandon execution of the normal sequence of statements. The trap door is used when an “exceptional condition” occurs, such that normal execution is no longer possible or desirable. Exceptions represent conditions that the current method is unable to handle. The reason exception handling systems were developed is because the approach of dealing with each possible error condition produced by each function call was too onerous, and programmers simply weren’t doing it. As a result, they were ignoring the errors. It’s worth observing that the issue of programmer convenience in handling errors was a prime motivation for exceptions in the first place. Feedback
One of the important guidelines in exception handling is “don’t catch an exception unless you know what to do with it.” In fact, one of the important goals of exception handling is to move the error-handling code away from the point where the errors occur. This allows you to focus on what you want to accomplish in one section of your code, and how you’re going to deal with problems in a distinct separate section of your code. As a result, your mainline code is not cluttered with error-handling logic, and it’s much easier to understand and maintain. Feedback
Checked exceptions complicate this scenario a bit, because they force you to add catch clauses in places where you may not be ready to handle an error. This results in the “harmful if swallowed” problem:
try {
// ... to do something useful
} catch(ObligatoryException e) {} // Gulp!
Programmers (myself included, in the first edition of this book) would just do the simplest thing, and swallow the exception—often unintentionally, but once you do it, the compiler has been satisfied, so unless you remember to revisit and correct the code, the exception will be lost. The exception happens, but it vanishes completely when swallowed. Because the compiler forces you to write code right away to handle the exception, this seems like the easiest solution even though it’s probably the worst thing you can do. Feedback
Horrified upon realizing that I had done this, in the second edition I “fixed” the problem by printing the stack trace inside the handler (as is still seen—appropriately—in a number of examples in this chapter). While this is useful to trace the behavior of exceptions, it still indicates that you don’t really know what to do with the exception at that point in your code. In this section we’ll look at some of the issues and complications arising from checked exceptions, and options that you have when dealing with them. Feedback
This topic seems simple. But it is not only complicated, it is also an issue of some volatility. There are people who are staunchly rooted on either side of the fence and who feel that the correct answer (theirs) is blatantly obvious. I believe the reason for one of these positions is the distinct benefit seen in going from a poorly-typed language like pre-ANSI C to a strong, statically-typed language (that is, checked at compile-time) like C++ or Java. When you make that transition (as I did), the benefits are so dramatic that it can seem like strong static type checking is always the best answer to most problems. My hope is to relate a little bit of my own evolution, that has brought the absolute value of strong static type checking into question; clearly, it’s very helpful much of the time, but there’s a fuzzy line we cross when it begins to get in the way and become a hindrance (one of my favorite quotes is: “All models are wrong. Some are useful.”). Feedback