熱點推薦:
您现在的位置: 電腦知識網 >> 編程 >> Java編程 >> Javascript >> 正文

構建更好的異常處理框架

2013-11-23 17:56:50  來源: Javascript 

  企業應用程序在構建時常常對異常處理關注甚少這會造成對低級異常(如 javarmiRemoteException 和 javaxnamingNamingException)的過度依賴在 EJB 最佳實踐的這篇專欄文章中Brett McLaughlin 解釋了為什麼對異常處理投入一點關注就會給我們帶來很大的幫助並向您展示了兩種簡單技術它們將幫助您正確地構建更健壯且有用的異常處理框架
  
  在本系列先前的技巧文章中異常處理不屬於討論的核心范圍之內但是您可能會發現一點那就是我們一直都回避來自 Web 層的低級異常我們向客戶機提供諸如 ApplicationException 和 InvalidDataException 之類的異常而沒有讓 Web 層處理象 javarmiRemoteException 或 javaxnamingNamingException 這樣的異常
  
  遠程和命名異常是系統級異常而應用程序和非法數據異常是業務級異常因為它們提交更適用的業務信息當決定拋出何種類型的異常時您應該總是首先考慮將要處理所報告異常的層Web 層通常是由執行業務任務的最終用戶驅動的所以最好用它處理業務級異常但是在 EJB 層您正在執行系統級任務如使用 JNDI 或數據庫盡管這些任務最終將被合並到業務邏輯中但是最好用諸如 RemoteException 之類的系統級異常來表示它們
  
  理論上您可以讓所有 Web 層方法預期處理和響應單個應用程序異常正如我們在先前的一些示例中所做的一樣但這種方法不適用於長時間運行讓您的委派方法拋出更具體的異常這是一個好得多的異常處理方案從根本上講這對接收客戶機更有用在這篇技巧文章中我們將討論兩種技術它們將有助於您創建信息更豐富更具體的異常而不會生成大量不必要的代碼
  
  嵌套的異常
  在設計可靠的異常處理方案時要考慮的第一件事情就是對所謂的低級或系統級異常進行抽象化這些核心 Java 異常通常會報告網絡流量中的錯誤JNDI 或 RMI 問題或者是應用程序中的其它技術問題RemoteExceptionEJBException 和 NamingException 是企業 Java 編程中低級異常的常見例子
  
  這些異常完全沒有任何意義由 Web 層的客戶機接收時尤其容易混淆如果客戶機調用 purchase() 並接收到 NamingException那麼它在解決這個異常時會一籌莫展同時應用程序代碼可能需要訪問這些異常中的信息因此不能輕易地拋棄或忽略它們
  
  答案是提供一類更有用的異常它還包含低級異常清單 演示了一個專為這一點設計的簡單 ApplicationException
  
  清單 嵌套的異常 package comibm;
  import javaioPrintStream;
  import javaioPrintWriter;
  public class ApplicationException extends Exception {
  /** A wrapped Throwable */
  protected Throwable cause;
  public ApplicationException() {
  super(Error occurred in application);
  }
  public ApplicationException(String message) {
  super(message);
  }
  public ApplicationException(String message Throwable cause) {
  super(message);
  thiscause = cause;
  }
  // Created to match the JDK Throwable method
  public Throwable initCause(Throwable cause) {
  thiscause = cause;
  return cause;
  }
  public String getMessage() {
  // Get this exceptions message
  String msg = supergetMessage();
  Throwable parent = this;
  Throwable child;
  // Look for nested exceptions
  while((child = getNestedException(parent)) != null) {
  // Get the childs message
  String msg = childgetMessage();
  // If we found a message for the child exception
  // we append it
  if (msg != null) {
  if (msg != null) {
  msg += : + msg;
  } else {
  msg = msg;
  }
  }
  // Any nested ApplicationException will append its own
  // children so we need to break out of here
  if (child instanceof ApplicationException) {
  break;
  }
  parent = child;
  }
  // Return the completed message
  return msg;
  }
  public void printStackTrace() {
  // Print the stack trace for this exception
  superprintStackTrace();
  Throwable parent = this;
  Throwable child;
  // Print the stack trace for each nested exception
  while((child = getNestedException(parent)) != null) {
  if (child != null) {
  Systemerrprint(Caused by: );
  childprintStackTrace();
  if (child instanceof ApplicationException) {
  break;
  }
  parent = child;
  }
  }
  }
  public void printStackTrace(PrintStream s) {
  // Print the stack trace for this exception
  superprintStackTrace(s);
  Throwable parent = this;
  Throwable child;
  // Print the stack trace for each nested exception
  while((child = getNestedException(parent)) != null) {
  if (child != null) {
  sprint(Caused by: );
  childprintStackTrace(s);
  if (child instanceof ApplicationException) {
  break;
  }
  parent = child;
  }
  }
  }
  public void printStackTrace(PrintWriter w) {
  // Print the stack trace for this exception
  superprintStackTrace(w);
  Throwable parent = this;
  Throwable child;
  // Print the stack trace for each nested exception
  while((child = getNestedException(parent)) != null) {
  if (child != null) {
  wprint(Caused by: );
  childprintStackTrace(w);
  if (child instanceof ApplicationException) {
  break;
  }
  parent = child;
  }
  }
  }
  public Throwable getCause() {
  return cause;
  }
  }
  
  清單 中的代碼很簡單我們已經簡單地將多個異常在一起以創建單個嵌套的異常但是真正的好處在於將這種技術作為出發點以創建特定於應用程序的異常層次結構異常層次結構將允許 EJB 客戶機既接收特定於業務的異常也接收特定於系統的信息而不需要編寫大量額外代碼
  
  異常層次結構
  異常層次結構應該從一些十分健壯而又通用的異常入手如 ApplicationException如果您將頂級異常搞得太具體那麼其結果是您今後將不得不重新構造層次結構以適應某些較通用的情況
  
  因此讓我們假定您的應用程序要求 NoSuchBookExceptionInsufficientFundsException 和 SystemUnavailableException您不必創建這三個異常讓它們繼承 ApplicationException然後只需提供極少幾個必須的構造器來創建格式化的消息清單 是此類異常層次結構的示例
  
  清單 異常層次結構 package comibmlibrary;
  import comibmApplicationException;
  public class NoSuchBookException extends ApplicationException {
  public NoSuchBookException(String bookName String libraryName) {
  super(The book + bookName + was not found in the +
  libraryName + library);
  }
  }
  
  當需要編寫大量專用異常時異常層次結構極大地簡化了工作對於一個異常為每個異常類添加一個或兩個構造器所花費時間很少不超過幾分鐘您還經常需要給這些更具體的異常(這些異常也是主應用程序異常的子類)提供子類以提供更具體的異常例如您可能需要 InvalidTitleException 和 BackorderedException 來繼承 NoSuchBookException
  
  企業應用程序在構建時通常都不會注意異常處理盡管依靠低級異常(如 RemoteException 和 NamingException)很容易(有時也很誘人)但如果一開始就建立一個可靠的深思熟慮的異常模型則您將在應用程序上少花很多精力創建一個嵌套的層次結構化的異常框架將改進代碼的可讀性及其可用性
From:http://tw.wingwit.com/Article/program/Java/Javascript/201311/25400.html
    推薦文章
    Copyright © 2005-2013 電腦知識網 Computer Knowledge   All rights reserved.