【導讀】Java開發(fā)人員可以做出的最重要的架構(gòu)性決策之一就是如何使用Java異常模型。直以來就是人們爭議的焦點。有人爭論到，在Java語言中的異常檢查已是一場失敗的試驗。本文倡導一種對異常條件本質(zhì)的思考方式，并描述一些有助于設計的模式。最后，本文還將在。AOP模型中，作為相互滲透的問題，來討論異常的處理。本文將幫助你做到這一點。Java應用中的異常處理在很大程度上揭示了其所基于架構(gòu)的強度。序各個層次上所做出并遵循的決定。統(tǒng)，或?qū)又g溝通的方式。Java異常是Java方法將另類執(zhí)行結(jié)果交流出去的方式，所。以值得在應用架構(gòu)中給予特殊關(guān)注。干凈，簡捷，關(guān)聯(lián)性強的異常處理通常表明開發(fā)團隊有。那么原因很有可能要歸咎于組件的報錯設計。編譯時的異常檢查也能起到類似的作用，它會提醒開發(fā)人員某。“檢察的異?！鳖愋鸵?比1的比率超過了“未檢查的異常”類型。兩種應變的回應則是需要與支票。清算端溝通的在銀行領(lǐng)域?qū)崒嵲谠诖嬖诘那闆r。processCheck方法所有3種返回結(jié)

　　

【正文】 conditions that these frameworks report are unrecoverable, stemming from incorrect coding of a method call, or a failure of some underlying ponent such as a database server. Practically speaking, there is almost no benefit to be gained by forcing a caller to catch or declare such exceptions. Fault handling in your architecture The first step toward handling faults effectively in your architecture is to admit that you need to do it. Coming to this acceptance is difficult for engineers who take pride in their ability to create impeccable software. Here is some reasoning that will help. First, your application will be spending a great deal of time in development where mistakes are monplace. Providing for programmergenerated faults will make it easier for your team to diagnose and fix them. Second, the (over)use of checked exceptions in the Java library for fault conditions will force your code to deal with them, even if your calling sequences are pletely correct. If there39。s no fault handling framework in place, the resulting makeshift exception handling will inject entropy into your application. A successful fault handling framework has to acplish four goals: ? Minimize code clutter ? Capture and preserve diagnostics ? Alert the right person ? Exit the activity gracefully Faults are a distraction from your application39。s real purpose. Therefore, the amount of code devoted to processing them should be minimal and, ideally, isolated from the semantic parts of the application. Fault processing must serve the needs of the people responsible for correcting them. They need to know that a fault happened and get the information that will help them figure out why. Even though a fault, by definition, is not recoverable, good fault handling will attempt to terminate the activity that encountered the fault in a graceful way. Use unchecked exceptions for fault conditions There are lots of reasons to make the architectural decision to represent fault conditions with unchecked exceptions. The Java runtime rewards programming mistakes by throwing RuntimeException subclasses such as ArithmeticException and ClassCastException, setting a precedent for your architecture. Unchecked exceptions minimize clutter by freeing upstream methods from the requirement to include code for conditions that are irrelevant to their purpose. Your fault handling strategy should recognize that methods in the Java library and other APIs may use checked exceptions to represent what could only be fault conditions in the context of your application. In this case, adopt the architectural convention to catch the API exception where it happens, treat it as a fault, and throw an unchecked exception to signal the fault condition and capture diagnostic information. The specific exception type to throw in this situation should be defined by your architecture. Don39。t fet that the primary purpose of a fault exception is to convey diagnostic information that will be recorded to help people figure out what went wrong. Using multiple fault exception types is probably overkill, since your architecture will treat them all identically. A good, descriptive message embedded inside a single fault exception type will do the job in most cases. It39。s easy to defend using Java39。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 dealing with faults will pay benefits down the road. In the fault barrier pattern, any application ponent can throw a fault exception, but only the ponent acting as the fault barrier catches them. Adopting this pattern eliminates much of the intricate code that developers insert locally to deal with faults. The fault barrier resides logically toward the top of the call stack where it stops the upward propagation of an exception before default action is triggered. Default action means different things depending on the application type. For a standalone Java application, it means that the active thread is terminated. For a Web application hosted by an application server, it means that the application server sends an unfriendly (and embarrassing) response to the browser. The first responsibility of a fault barrier ponent is to record the information contained in the fault exception for future action. An application log is by far the best place to do this. The exception39。s chained messages, stack traces, and so on, are all valuable pieces of information for diagnosticians. The worst place to send fault information is across the user interface. Involving the client of your application in your debugging process is hardly ever good for you or your client. If you are really tempted to paint the user interface with diagnostic information, it probably means that your logg