【正文】 architecture. Don39。s intended purpose. The caller of the method expects these kinds of conditions and has a strategy for coping with them. Fault An unplanned condition that prevents a method from achieving its intended purpose that cannot be described without reference to the method39。s exception model has been the subject of considerable debate. Java was not the first language to support exceptionlike semantics。 AOP 技術(shù)將故障和應(yīng)變定位為相互滲透的問題，這個方法可能會對你的架構(gòu)提供一些幫助。這樣，把參與者綁定在故障屏障的模式可以放松些。它們意味著你的應(yīng)用正在如最初的設(shè)計(jì)般正常工作著。 提供一些有用的信息 定義不同的故障報告的異常類型是沒什 么道理的，因?yàn)楣收掀琳蠈λ挟惓ｎ愋鸵灰曂省?Java I/O的方法通常返回一個整數(shù)值－ 1，而不是字節(jié)的值或字節(jié)的數(shù)來表示文件的結(jié)尾。 當(dāng)你的架構(gòu)包含了故障屏障，程序員都知曉了后，再寫出一次性的故障異常的沖動就會銳減。如果你的應(yīng)用是一個 Web service，這就意味著在回應(yīng)中用 soap:Server 的 faultcode和通用的失敗信息 faultstring來建立一個 SOAP 故障元素 fault。 一個故障屏障組件的第一要務(wù)就是記錄下故障異常中包含的信息以為將來所用。這里的目的是讓你應(yīng)用中的功能性部分不需要處理故障。截止到 ， RuntimeException，和其他的拋出類型一樣， 都支持異常的嵌套，這樣你就可以捕獲和報出導(dǎo)向故障的檢查的異常。未檢查的異常讓上游的調(diào)用方法不需要為和它們目的不相關(guān)的情況而添加代碼，從而減少了混亂。 故障是應(yīng)用的真實(shí)意圖的干擾。這里是一些有幫助的思考方式。他們讓故障的通知原封不動地從調(diào)用棧上所有的方法濾過，到達(dá)一個專門來捕獲它們的地方，并得到它們自身包含的有利于診斷的信息，對整個事件提供一個有節(jié)制的優(yōu)雅的結(jié)論。 Java 異常的匹配 在建立應(yīng)用架構(gòu)中 Java 異常的規(guī)則時，以應(yīng)變和故障的方式仔細(xì)考慮好 “ 什么可能會出錯 ” 是有長遠(yuǎn)意義的。在調(diào)用棧里上游的方法能處理這些問題的可能就更小。這些異常和由于 CheckingAccount 類中一些內(nèi)部實(shí)施細(xì)則引起的真正失敗是 不同的。 在 Java 里，一個自然的方法來表示上述緊急的應(yīng)變是定義兩種異常，比如StopPaymentException（止付異常）和 InsufficientFundsException（余額不足異常 ）。一個 CheckingAcccount 對象必須協(xié)調(diào)同步線程的訪問，因?yàn)槿魏我粋€線程都可能改變它的狀態(tài)。這樣你的實(shí)施細(xì)則就不得不暴露在外了，而通常好的面向?qū)ο蟮脑O(shè)計(jì)都是要隱藏 細(xì)節(jié)的。例如， 包 。 我可以想象那些接受 “ 檢查 ” 的異常的人，也會很看重 Java 的數(shù)據(jù)類型。許多人都認(rèn)為編譯時的異常檢查對精確的軟件設(shè)計(jì)頗有幫助。錯誤的報錯系統(tǒng)會 在客戶端產(chǎn)生大量的“ 記錄然后忘掉 ” 的代碼，這些代碼鮮有用途。干凈，簡捷，關(guān)聯(lián)性強(qiáng)的異常處理通常表明開發(fā)團(tuán)隊(duì)有著穩(wěn)定的使用 Java 異常的方式。當(dāng)你能正確使用異常時，它們會有極大的好處。 Java 異常一直以來就是 人們 爭議的 焦點(diǎn) 。架構(gòu)是在應(yīng)用程序各個層次上所做出并遵循的決定。如果你問問團(tuán)隊(duì)成員為什么異常會被拋出，捕獲，或在特定的一處代碼里忽視了異常的發(fā)生，他們的回答通常是， “ 我沒有別的可做 ” 。異常處理是一個在設(shè)計(jì)的各個部分都急需解決的問題。這些簡單的規(guī)則對世界范圍的 Java 程序員都有深遠(yuǎn)的影響。編譯時的異常檢查也能起到類似的作用，它會提醒開發(fā)人員某個方法可能會有預(yù)想不到的結(jié)果需要處理好。 圖 1： Java 異常等級層次圖 I/O 的失敗極其稀有，但是卻很嚴(yán)重。 一些 Java 界的知名人物開始質(zhì)疑 Java 的 “ 檢察的異常 ” 的模型是否是一個失敗的試驗(yàn)。一，CheckingAccount 對象里可能對該支票已有一個止付的命令；二，帳戶的余額可 能不足已滿足支票的金額。 客戶端可以很容易的處理好這兩種異常。比如，有人可能忘了把數(shù)據(jù)庫服務(wù)器運(yùn)行起來，一個未有連上的網(wǎng)絡(luò)數(shù)據(jù)線，訪問數(shù)據(jù)庫的密碼改變了，等等。這個方法的調(diào)用者預(yù)料到這個情況的出現(xiàn)，并有相對的應(yīng)付之道。如果你發(fā)現(xiàn)編譯器堅(jiān)持應(yīng)變的異常必須要處理或者在不方便的時候必須要聲明會給你帶來些麻煩，你在設(shè)計(jì)上幾乎肯定要做些重構(gòu)了。 Hibernate ORM 架構(gòu)在 版本里重新定義了一些關(guān)鍵功能來去除對檢查的異常的使用。如果沒有一個故障處理的架構(gòu)，湊合的異常處理將導(dǎo)致應(yīng)用中的信息丟失。開發(fā)人員需要知道故障發(fā)生了，并得到能 幫助他們搞清為何發(fā)生的信息。 在這種情況下拋出的特定異常類型應(yīng)該由你的框架來定義。實(shí)施一個類似的嵌套功能來捕獲和轉(zhuǎn)換你應(yīng)用中構(gòu)成故障的檢查的異常是很簡單的。采用此種模式去除了大多數(shù)程序員為了在本地處理故障而插入的復(fù)雜的代碼。傳遞故障信息最差的地方是通過用戶界面。你的故障屏障類將延伸 類，必要的話，重寫它的方法來實(shí)施用戶自己的特別處理。一個應(yīng)變代表著與主要返回結(jié)果同等重要的另外一種方法結(jié)果。但是，編譯器沒有辦法來保證方法調(diào)用者會使用這個判斷。 不要忘記你的異常應(yīng)該是百分百的 Java 類型，你可以用它來存放為你的特殊目的服務(wù)的特殊字段，方法，甚至是構(gòu)造器。 異常的各個方面 在 Aspect Oriented Programming（ AOP）的術(shù)語里，故障和應(yīng)變的處理是互相滲透的問題。對故障和應(yīng)變的處理在 AOP 架構(gòu)下的使用做一個完整的勘探將是將來論文里一個很有意思的題目。s discipline is to look at exception handling code inside their application. The first thing to observe is how much code is devoted to catching exceptions, logging them, trying to determine what happened, and translating one exception to another. Clean, pact, and coherent exception handling is a sign that the team has a consistent approach to using Java exceptions. When the amount of exception handling code threatens to outweigh everything else, you can tell that munication between team members has broken down (or was never there in the first place), and everyone is treating exceptions their own way. The results of ad hoc exception handling are very predictable. If you ask team members why they threw, caught, or ignored an exception at a particular point in their code, the response is usually, I didn39。s processCheck() method accepts a Check object as an argument and normally deducts the check amount from the account balance. But a checkclearing client that calls processCheck() must be ready for two contingencies. First, the CheckingAccount may have a stop payment order registered for the check. Second, the account may not have sufficient funds to cover the check amount. So, the processCheck() method can respond to its caller in three possible ways. The nominal response is that the check gets processed and the result declared in the method signature is returned to the invoking service. The two contingency responses represent very real situations in the banking domain that need to be municated to the checkclearing client. All three processCheck() responses were designed intentionally to model the behavior of a typical checking account. The natural way to represent the contingency responses in Java is to define two exceptions, say StopPaymentException and InsufficientFundsException. It wouldn39。s help to ensure that they are addressed. If you find that the piler is getting in the way by insisting that contingency exceptions be handled or declared when it is inconvenient, it39。s generic RuntimeException to represent your fault conditions. As of Java , RuntimeException, like all throwables, supports exception chaining, allowing you to capture and report a faultinducing checked exception. You may choose to define your own unchecked exception for the purpose of fault reporting. This would be necessary if you need to use Java or earlier versions that do not support exception chaining. It is simple to implement a similar chaining capability to capture and translate checked exceptions that constitute faults in your application. Your application may have a need for special behavior in a fault reporting exception. That would be another reason to create a subclass of RuntimeException for your architecture. Establish a fault barrier Deciding which exception to throw and when to throw it are important decisions for your faulthandling framework. Just as important are the questions of when to catch a fault exception and what to do afterward. The goal here is to free the functional portions of your application from the responsibility of processing faults. Separation of concerns is generally a good thing, and a central facility responsible for deali