異常處理

異常處理

異常處理,英文名為exceptional handling, 是代替日漸衰落的error code方法的新法,提供error code 所未能具體的優勢。異常處理分離了接收和處理錯誤代碼。這個功能理清了編程者的思緒,也幫助代碼增強了可讀性,方便了維護者的閱讀和理解。 異常處理(又稱為錯誤處理)功能提供了處理程式運行時出現的任何意外或異常情況的方法。異常處理使用 try、catch 和 finally 關鍵字來嘗試可能未成功的操作,處理失敗,以及在事後清理資源。

異常處理,是程式語言或計算機硬體里的一種機制,用於處理軟體或信息系統中出現的異常狀況(即超出程式正常執行流程的某些特殊條件)。

基本介紹

  • 中文名:異常處理
  • 外文名:exceptional handling
  • 代替:日漸衰落的error code方法
  • 又稱:錯誤處理
  • 領域:計算機
  • 作用:提供了處理異常情況的方法
  • 關鍵字:try、catch 和 finally 關鍵字
概述,程式設計語言的異常機制,名詞解釋,特點,基本模型,處理方法,php異常,Java異常處理,

概述

異常處理,是程式語言或計算機硬體里的一種機制,用於處理軟體或信息系統中出現的異常狀況(即超出程式正常執行流程的某些特殊條件)。
各種程式語言在處理異常方面具有非常顯著的不同點(錯誤檢測與異常處理區別在於:錯誤檢測是在正常的程式流中,處理不可預見問題的代碼,例如一個調用操作未能成功結束)。某些程式語言有這樣的函式:當輸入存在非法數據時不能被安全地調用,或者返回值不能與異常進行有效的區別。例如,C語言中的atoi函式(ASCII串到整數的轉換)在輸入非法時可以返回0。在這種情況下編程者需要另外進行錯誤檢測(可能通過某些輔助全局變數如C的errno),或進行輸入檢驗(如通過正則表達式),或者共同使用這兩種方法。
通過異常處理,我們可以對用戶在程式中的非法輸入進行控制和提示,以防程式崩潰。
從進程的視角,硬體中斷相當於可恢復異常,雖然中斷一般與程式流本身無關。
從子程式編程者的視角,異常是很有用的一種機制,用於通知外界該子程式不能正常執行。如輸入的數據無效(例如除數是0),或所需資源不可用(例如檔案丟失)。如果系統沒有異常機制,則編程者需要用返回值來標示發生了哪些錯誤。
異常處理

程式設計語言的異常機制

許多常見的程式設計語言,包括ActionscriptAda,BlitzMax,C++C#DECMAScriptEiffelJavaMLObject Pascal(如DelphiFree Pascal等),Objective-COcamlPHP(version 5),PL/1,PrologPythonREALbasicRubyVisual Prolog以及大多數.NET程式設計語言,內建的異常機制都是沿著函式調用棧的函式調用逆向搜尋,直到遇到異常處理代碼為止。一般在這個異常處理代碼的搜尋過程中逐級完成棧卷回(stack unwinding)。但Common Lisp是個例外,它不採取棧卷回,因此允許異常處理完後在拋出異常的代碼處原地恢復執行。而 Visual Basic(尤其是在其早於 .net 的版本,例如 6.0 中)走得更遠:on error 語句可輕易指定發生異常後是重試(resume)還是跳過(resume next)還是執行程式設計師定義的錯誤處理程式(goto ***)。
多數語言的異常機制的語法是類似的:用throw或raise拋出一個異常對象(Java或C++等)或一個特殊可擴展的枚舉類型的值(如Ada語言);異常處理代碼的作用範圍用標記子句(try或begin開始的語言作用域)標示其起始,以第一個異常處理子句(catch, except, resuce等)標示其結束;可連續出現若干個異常處理子句,每個處理特定類型的異常。某些語言允許else子句,用於無異常出現的情況。更多見的是finally, ensure子句,無論是否出現異常它都將執行,用於釋放異常處理所需的一些資源。
C++異常處理是資源獲取即初始化(Resource-Acquisition-Is-Initialization)的基礎。
C語言一般認為是不支持異常處理的。Perl語言可選擇支持結構化異常處理(structured exception handling)。
Python語言對異常處理機制是非常普遍深入的,所以想寫出不含try, except的程式非常困難。

名詞解釋

異常處理,英文名為exceptional handling, 是代替日漸衰落的error code方法的新法,提供error code 所未能具體的優勢。異常處理分離了接收和處理錯誤代碼。這個功能理清了編程者的思緒,也幫助代碼增強了可讀性,方便了維護者的閱讀和理解。
異常處理(又稱為錯誤處理)功能提供了處理程式運行時出現的任何意外或異常情況的方法。異常處理使用 try、catch 和 finally 關鍵字來嘗試可能未成功的操作,處理失敗,以及在事後清理資源。
異常處理通常是防止未知錯誤產生所採取的處理措施。異常處理的好處是你不用再絞盡腦汁去考慮各種錯誤,這為處理某一類錯誤提供了一個很有效的方法,使編程效率大大提高。
異常可以由公共語言運行庫(CLR)、第三方庫或使用 throw 關鍵字的應用程式代碼生成

特點

1.在應用程式遇到異常情況(如被零除情況或記憶體不足警告)時,就會產生異常。
2.發生異常時,控制流立即跳轉到關聯的異常處理程式(如果存在)。
3.如果給定異常沒有異常處理程式,則程式將停止執行,並顯示一條錯誤信息
4.可能導致異常的操作通過 try 關鍵字來執行。
5.異常處理程式是在異常發生時執行的代碼塊。在 C# 中,catch 關鍵字用於定義異常處理程式。
6.程式可以使用 throw 關鍵字顯式地引發異常。
7.異常對象包含有關錯誤的詳細信息,其中包括調用堆疊的狀態以及有關錯誤的文本說明。
8.即使引發了異常,finally 塊中的代碼也會執行,從而使程式可以釋放資源。

基本模型

一種稱為"終止模型"(它是Java與C++所支持的模型).在這種模型中,將假設錯誤非常關鍵,將以致於程式無法返回到異常發生的地方繼續執行.一旦異常被拋出,就表明錯誤已無法挽回,也不能回來繼續執行.
另一種稱為"恢復模型".意思是異常處理程式的工作是修正錯誤,然後重新嘗試調動出問題的方法,並認為第二次能成功.
對於恢復模型,通常希望異常被處理之後能繼續執行程式.在這種情況下,拋出異常更像是對方法的調用--可以在Java里用這種方法進行配置,以得到類似恢復的行為.(也就是說,不是拋出異常,而是調用方法修正錯誤.)或者,把try塊放在while循環里,這樣就可以不斷的進入try塊,直到得到滿意的結果.
雖然恢復模型開始顯得很吸引人,並且人們使用的作業系統也支持恢復模型的異常處理,但程式設計師們最終還是轉向了使用類似"終止模型"的代碼.因為:處理程式必須關注異常拋出的地點,這勢必要包含依賴於拋出位置的非通用性代碼.這增加了代碼編寫和維護的困難,對於異常可能會從許多地方拋出的大型程式來說,更是如此.
下面我寫的一個簡單的例子 VC++6.0下通過
#include <iostream>
using namespace std;
class Error
public:
virtual void show()=0;
class DenoError:public Error
public:
void show()
cout<<"分母不可以為0!"<<endl;
void main()
int a,b;
cin>>a>>b;
try
DenoError e;
if(b==0)
throw e;
int c=a/b;
cout<<c<<endl;
catch(DenoError & e)
e.show();

處理方法

php異常

擴展 php 內置的異常處理類
用戶可以用自定義的異常處理類來擴展 php 內置的異常處理類。以下的代碼說明了在內置的異常處理類中,哪些屬性和方法在子類中是可訪問和可繼承的。譯者註:以下這段代碼只為說明內置異常處理類的結構,它並不是一段有實際意義的可用代碼。
內置的異常處理類
<?php class Exception { protected $message = 'Unknown exception' ; // 異常信息 protected $code = 0 ; // 用戶自定義異常代碼 protected $file ; // 發生異常的檔案名稱 protected $line ; // 發生異常的代碼行號 function __construct $message = null $code = 0 ); final function getMessage (); // 返回異常信息 final function getCode (); // 返回異常代碼 final function getFile (); // 返回發生異常的檔案名稱 final function getLine (); // 返回發生異常的代碼行號 final function getTrace (); // backtrace() 數組 final function getTraceAsString (); // 已格成化成字元串的 getTrace() 信息 /* 可重載的方法 */ function __toString (); // 可輸出的字元串 } ?>如果使用自定義的類來擴展內置異常處理類,並且要重新定義構造函式的話,建議同時調用 parent::__construct() 來檢查所有的變數是否已被賦值。當對象要輸出字元串的時候,可以重載 __toString() 並自定義輸出的樣式。
擴展 php 內置的異常處理類
<?php /** * 自定義一個異常處理類 */ class MyException extends Exception{ // 重定義構造器使 message 變為必須被指定的屬性 public function __construct( $message $code = 0 ) { , // 自定義的代碼 // 確保所有變數都被正確賦值 parent:: __construct ( $message $code ); } // 自定義字元串輸出的樣式 */ public function __toString () { return __CLASS__ . ": [{ $this -> code }] : {$this->message }/n " ; } public function customFunction () { echo "A Custom function for this type of exception/n" ; }} /** * 創建一個用於測試異常處理機制的類 */class TestException { public $var ; const THROW_NONE = 0 ; const THROW_CUSTOM = 1 ; const THROW_DEFAULT = 2 ; function __construct( $avalue = self :: THROW_NONE ) { switch ( $avalue ) { case self :: THROW_CUSTOM : // 拋出自定義異常 throw new MyException ( '1 is an invalid parameter' 5 ); break; case self:: THROW_DEFAULT: // 拋出默認的異常 throw new Exception ( '2 isnt allowed as a parameter' 6 ); break; default: // 沒有異常的情況下,創建一個對象 $this var = $avalue ; break; } }}

Java異常處理

你覺得自己是一個Java專家嗎?北京海淀甲骨文學習中心幫你全面掌握了Java的異常處理機制?在下面這段代碼中,你能夠迅速找出異常處理的六個問題嗎?
OutputStreamWriter out = ... java.sql.Connection conn = ... try { // ⑸  Statement stat = conn.createStatement();  ResultSet rs = stat.executeQuery("select uid, name from user");  while (rs.next())  {      out.println("ID:" + rs.getString("uid") // ⑹    +",姓名:" + rs.getString("name"));      }      conn.close(); // ⑶      out.close(); } catch(Exception ex) // ⑵ {  ex.printStackTrace(); //⑴,⑷ }
作為一個Java程式設計師,你至少應該能夠找出兩個問題。但是,如果你不能找出全部六個問題,請繼續閱讀本文。
本文討論的不是Java異常處理的一般性原則,因為這些原則已經被大多數人熟知。我們要做的是分析各種可稱為“反例”(anti-pattern)的違背優秀編碼規範的常見壞習慣,幫助讀者熟悉這些典型的反面例子,從而能夠在實際工作中敏銳地察覺和避免這些問題。
反例之一:丟棄異常
代碼:12行-15行。
這段代碼捕獲了異常卻不作任何處理,可以算得上Java編程中的殺手。從問題出現的頻繁程度和禍害程度來看,它也許可以和C/C++程式的一個惡名遠播的問題相提並論??不檢查緩衝區是否已滿。如果你看到了這種丟棄(而不是拋出)異常的情況,可以百分之九十九地肯定代碼存在問題(在極少數情況下,這段代碼有存在的理由,但最好加上完整的注釋,以免引起別人誤解)。
這段代碼的錯誤在於,異常(幾乎)總是意味著某些事情不對勁了,或者說至少發生了某些不尋常的事情,我們不應該對程式發出的求救信號保持沉默和無動於衷。調用一下printStackTrace算不上“處理異常”。不錯,調用printStackTrace對調試程式有幫助,但程式調試階段結束之後,printStackTrace就不應再在異常處理模組中擔負主要責任了。
丟棄異常的情形非常普遍。打開JDK的ThreadDeath類的文檔,可以看到下面這段說明:“特別地,雖然出現ThreadDeath是一種‘正常的情形’,但ThreadDeath類是Error而不是Exception的子類,因為許多套用會捕獲所有的Exception然後丟棄它不再理睬。”這段話的意思是,雖然ThreadDeath代表的是一種普通的問題,但鑒於許多套用會試圖捕獲所有異常然後不予以適當的處理,所以JDK把ThreadDeath定義成了Error的子類,因為Error類代表的是一般的套用不應該去捕獲的嚴重問題。可見,丟棄異常這一壞習慣是如此常見,它甚至已經影響到了Java本身的設計。
那么,應該怎樣改正呢?主要有四個選擇:
1、處理異常。針對該異常採取一些行動,例如修正問題、提醒某個人或進行其他一些處理,要根據具體的情形確定應該採取的動作。再次說明,調用printStackTrace算不上已經“處理好了異常”。
2、重新拋出異常。處理異常的代碼在分析異常之後,認為自己不能處理它,重新拋出異常也不失為一種選擇。
3、把該異常轉換成另一種異常。大多數情況下,這是指把一個低級的異常轉換成套用級的異常(其含義更容易被用戶了解的異常)。
4、不要捕獲異常。
結論一:既然捕獲了異常,就要對它進行適當的處理。不要捕獲異常之後又把它丟棄,不予理睬。
反例之二:不指定具體的異常
代碼:12行。
許多時候人們會被這樣一種“美妙的”想法吸引:用一個catch語句捕獲所有的異常。最常見的情形就是使用catch(Exception ex)語句。但實際上,在絕大多數情況下,這種做法不值得提倡。為什麼呢?
要理解其原因,我們必須回顧一下catch語句的用途。catch語句表示我們預期會出現某種異常,而且希望能夠處理該異常。異常類的作用就是告訴Java編譯器我們想要處理的是哪一種異常。由於絕大多數異常都直接或間接從java.lang.Exception派生,catch(Exception ex)就相當於說我們想要處理幾乎所有的異常。
再來看看前面的代碼例子。我們真正想要捕獲的異常是什麼呢?最明顯的一個是SQLException,這是JDBC操作中常見的異常。另一個可能的異常是IOException,因為它要操作OutputStreamWriter。顯然,在同一個catch塊中處理這兩種截然不同的異常是不合適的。如果用兩個catch塊分別捕獲SQLException和IOException就要好多了。這就是說,catch語句應當儘量指定具體的異常類型,而不應該指定涵蓋範圍太廣的Exception類。
另一方面,除了這兩個特定的異常,還有其他許多異常也可能出現。例如,如果由於某種原因,executeQuery返回了null,該怎么辦?答案是讓它們繼續拋出,即不必捕獲也不必處理。實際上,我們不能也不應該去捕獲可能出現的所有異常,程式的其他地方還有捕獲異常的機會??直至最後由JVM處理。
結論二:在catch語句中儘可能指定具體的異常類型,必要時使用多個catch。不要試圖處理所有可能出現的異常。
反例之三:占用資源不釋放
代碼:3行-11行。
異常改變了程式正常的執行流程。這個道理雖然簡單,卻常常被人們忽視。如果程式用到了檔案、Socket、JDBC連線之類的資源,即使遇到了異常,也要正確釋放占用的資源。為此,Java提供了一個簡化這類操作的關鍵字finally。
finally是樣好東西:不管是否出現了異常,Finally保證在try/catch/finally塊結束之前,執行清理任務的代碼總是有機會執行。遺憾的是有些人卻不習慣使用finally。
當然,編寫finally塊應當多加小心,特別是要注意在finally塊之內拋出的異常??這是執行清理任務的最後機會,儘量不要再有難以處理的錯誤。
結論三:保證所有資源都被正確釋放。充分運用finally關鍵字。
反例之四:不說明異常的詳細信息
代碼:3行-11行。
仔細觀察這段代碼:如果循環內部出現了異常,會發生什麼事情?我們可以得到足夠的信息判斷循環內部出錯的原因嗎?不能。我們只能知道當前正在處理的類發生了某種錯誤,但卻不能獲得任何信息判斷導致當前錯誤的原因。
printStackTrace的堆疊跟蹤功能顯示出程式運行到當前類的執行流程,但只提供了一些最基本的信息,未能說明實際導致錯誤的原因,同時也不易解讀。
因此,在出現異常時,最好能夠提供一些文字信息,例如當前正在執行的類、方法和其他狀態信息,包括以一種更適合閱讀的方式整理和組織printStackTrace提供的信息。
結論四:在異常處理模組中提供適量的錯誤原因信息,組織錯誤信息使其易於理解和閱讀。
反例之五:過於龐大的try塊
代碼:3行-11行。
經常可以看到有人把大量的代碼放入單個try塊,實際上這不是好習慣。這種現象之所以常見,原因就在於有些人圖省事,不願花時間分析一大塊代碼中哪幾行代碼會拋出異常、異常的具體類型是什麼。把大量的語句裝入單個巨大的try塊就象是出門旅遊時把所有日常用品塞入一個大箱子,雖然東西是帶上了,但要找出來可不容易。
一些新手常常把大量的代碼放入單個try塊,然後再在catch語句中聲明Exception,而不是分離各個可能出現異常的段落並分別捕獲其異常。這種做法為分析程式拋出異常的原因帶來了困難,因為一大段代碼中有太多的地方可能拋出Exception。
結論五:儘量減小try塊的體積。
反例之六:輸出數據不完整
代碼:7行-8行。
不完整的數據是Java程式的隱形殺手。仔細觀察這段代碼,考慮一下如果循環的中間拋出了異常,會發生什麼事情。循環的執行當然是要被打斷的,其次,catch塊會執行??就這些,再也沒有其他動作了。已經輸出的數據怎么辦?使用這些數據的人或設備將收到一份不完整的(因而也是錯誤的)數據,卻得不到任何有關這份數據是否完整的提示。對於有些系統來說,數據不完整可能比系統停止運行帶來更大的損失。
較為理想的處置辦法是向輸出設備寫一些信息,聲明數據的不完整性;另一種可能有效的辦法是,先緩衝要輸出的數據,準備好全部數據之後再一次性輸出。
結論六:全面考慮可能出現的異常以及這些異常對執行流程的影響。
改寫後的代碼
根據上面的討論,下面給出改寫後的代碼。也許有人會說它稍微有點囉嗦,但是它有了比較完備的異常處理機制。
OutputStreamWriter out = ... java.sql.Connection conn = ...     try {           Statement stat = conn.createStatement();              ResultSet rs = stat.executeQuery("select uid, name from user");                while (rs.next()){                       out.println("ID:" + rs.getString("uid") + ",姓名: " +                  rs.getString("name"));                }          } catch(SQLException sqlex) {                   out.println("警告:數據不完整");                   throw new ApplicationException("讀取數據時出現SQL錯誤", sqlex);             } catch(IOException ioex) {                      hrow new ApplicationException("寫入數據時出現IO錯誤", ioex);               } finally{                          if (conn != null) {                        try {  conn.close();                         } catch(SQLException sqlex2) {                             System.err(this.getClass().getName() +                       ".mymethod - 不能關閉資料庫連線: " + sqlex2.toString());                                       }                          }                         if (out != null) {                            try {                              out.close();                             }catch(IOException ioex2) {                             System.err(this.getClass().getName() +                         ".mymethod - 不能關閉輸出檔案" + ioex2.toString());                               }                          }}

相關詞條

熱門詞條

聯絡我們