Item 73: Throw exceptions appropriate to the abstraction（拋出能用抽象解釋的異常） · Effective Java 3rd Edition

## Chapter 10. Exceptions（異常） ### Item 73: Throw exceptions appropriate to the abstraction（拋出能用抽象解釋的異常） It is disconcerting when a method throws an exception that has no apparent connection to the task that it performs. This often happens when a method propagates an exception thrown by a lower-level abstraction. Not only is it disconcerting, but it pollutes the API of the higher layer with implementation details. If the implementation of the higher layer changes in a later release, the exceptions it throws will change too, potentially breaking existing client programs. 當一個方法拋出一個與它所執行的任務沒有明顯關聯的異常時，這是令人不安的。這種情況經常發生在由方法傳播自低層抽象拋出的異常。它不僅令人不安，而且讓實現細節污染了上層的 API。如果高層實現在以后的版本中發生變化，那么它拋出的異常也會發生變化，可能會破壞現有的客戶端程序。 To avoid this problem, **higher layers should catch lower-level exceptions and, in their place, throw exceptions that can be explained in terms of the higher-level abstraction.** This idiom is known as exception translation: 為了避免這個問題，**高層應該捕獲低層異常，并確保拋出的異常可以用高層抽象解釋。** 這個習慣用法稱為異常轉換： ``` // Exception Translation try { ... // Use lower-level abstraction to do our bidding } catch (LowerLevelException e) { throw new HigherLevelException(...); } ``` Here is an example of exception translation taken from the AbstractSequentialList class, which is a skeletal implementation (Item 20) of the List interface. In this example, exception translation is mandated by the specification of the get method in the `List<E>` interface: 下面是來自 AbstractSequentialList 類的異常轉換示例，該類是 List 接口的一個框架實現（[Item-20](/Chapter-4/Chapter-4-Item-20-Prefer-interfaces-to-abstract-classes.md)）。在本例中，異常轉換是由 `List<E>` 接口中的 get 方法規范強制執行的： ``` /** * Returns the element at the specified position in this list. * @throws IndexOutOfBoundsException if the index is out of range * ({@code index < 0 || index >= size()}). */ public E get(int index) { ListIterator<E> i = listIterator(index); try { return i.next(); } catch (NoSuchElementException e) { throw new IndexOutOfBoundsException("Index: " + index); } } ``` A special form of exception translation called exception chaining is called for in cases where the lower-level exception might be helpful to someone debugging the problem that caused the higher-level exception. The lower-level exception (the cause) is passed to the higher-level exception, which provides an accessor method (Throwable’s getCause method) to retrieve the lower-level exception: 如果低層異常可能有助于調試高層異常的問題，則需要一種稱為鏈式異常的特殊異常轉換形式。低層異常（作為原因）傳遞給高層異常，高層異常提供一個訪問器方法（Throwable 的 getCause 方法）來檢索低層異常： ``` // Exception Chaining try { ... // Use lower-level abstraction to do our bidding } catch (LowerLevelException cause) { throw new HigherLevelException(cause); } ``` The higher-level exception’s constructor passes the cause to a chaining-aware superclass constructor, so it is ultimately passed to one of Throwable’s chaining-aware constructors, such as Throwable(Throwable): 高層異常的構造函數將原因傳遞給能夠接收鏈式異常的超類構造函數，因此它最終被傳遞給 Throwable 的一個接收鏈式異常的構造函數，比如 `Throwable(Throwable)`： ``` // Exception with chaining-aware constructor class HigherLevelException extends Exception { HigherLevelException(Throwable cause) { super(cause); } } ``` Most standard exceptions have chaining-aware constructors. For exceptions that don’t, you can set the cause using Throwable’s initCause method. Not only does exception chaining let you access the cause programmatically (with getCause), but it integrates the cause’s stack trace into that of the higher-level exception. 大多數標準異常都有接收鏈式異常的構造函數。對于不支持鏈式異常的異常，可以使用 Throwable 的 initCause 方法設置原因。異常鏈接不僅允許你以編程方式訪問原因（使用 getCause），而且還將原因的堆棧跟蹤集成到更高層異常的堆棧跟蹤中。 **While exception translation is superior to mindless propagation of exceptions from lower layers, it should not be overused.** Where possible, the best way to deal with exceptions from lower layers is to avoid them, by ensuring that lower-level methods succeed. Sometimes you can do this by checking the validity of the higher-level method’s parameters before passing them on to lower layers. 雖然異常轉換優于底層異常的盲目傳播，但它不應該被過度使用。在可能的情況下，處理低層異常的最佳方法是確保低層方法避免異常。有時，你可以在將高層方法的參數傳遞到低層之前檢查它們的有效性。 If it is impossible to prevent exceptions from lower layers, the next best thing is to have the higher layer silently work around these exceptions, insulating the caller of the higher-level method from lower-level problems. Under these circumstances, it may be appropriate to log the exception using some appropriate logging facility such as java.util.logging. This allows programmers to investigate the problem, while insulating client code and the users from it. 如果不可能從低層防止異常，那么下一個最好的方法就是讓高層靜默處理這些異常，使較高層方法的調用者免受低層問題的影響。在這種情況下，可以使用一些適當的日志工具（如 `java.util.logging`）來記錄異常。這允許程序員研究問題，同時將客戶端代碼和用戶與之隔離。 In summary, if it isn’t feasible to prevent or to handle exceptions from lower layers, use exception translation, unless the lower-level method happens to guarantee that all of its exceptions are appropriate to the higher level. Chaining provides the best of both worlds: it allows you to throw an appropriate higherlevel exception, while capturing the underlying cause for failure analysis (Item 75). 總之，如果無法防止或處理來自低層的異常，則使用異常轉換，但要保證低層方法的所有異常都適用于較高層。鏈式異常提供了兼顧兩方面的最佳服務：允許拋出適當的高層異常，同時捕獲并分析失敗的潛在原因（[Item-75](/Chapter-10/Chapter-10-Item-75-Include-failure-capture-information-in-detail-messages.md)）。 --- **[Back to contents of the chapter（返回章節目錄）](/Chapter-10/Chapter-10-Introduction.md)** - **Previous Item（上一條目）：[Item 72: Favor the use of standard exceptions（鼓勵復用標準異常）](/Chapter-10/Chapter-10-Item-72-Favor-the-use-of-standard-exceptions.md)** - **Next Item（下一條目）：[Item 74: Document all exceptions thrown by each method（為每個方法記錄會拋出的所有異常）](/Chapter-10/Chapter-10-Item-74-Document-all-exceptions-thrown-by-each-method.md)**