VFP 愛用者社區

Ruey · 註冊時間: 2003-03-12 文章: 1698 來自: tunglo 第 1 樓

有本事就來抓我吧！
作者：Doug Hennig
譯者：fbilo
VFP 8 有了結構化錯誤處理，它的特徵是新的TRY...CATCH...FINALLY...ENDTRY 結
構。這個強大的新功能向我們提供了錯誤處理的第三個層次，並讓你可以省下大量的傳遞和
處理錯誤資訊的代碼。這個月，Doug Hennig 討論了結構化錯誤處理，並演示了怎樣將它集
成到一個完整的錯誤處理策略中去。
正文：
VFP 3 通過給物件增加了一個Error 方法極大的增強了錯誤處理能力。它讓物件可以
封裝它們自己的錯誤處理，並且不需要依賴於全局的錯誤處理器。不過，把代碼放在對象的
Error 方法中的一個缺點是：它排斥了ON Error 命令的使用。這麼做是有道理的，因為不
然的話就會破壞錯誤處理的封裝。但是，這就導致了一個問題，如果一個物件的Error 方
法代碼中調用了過程代碼（例如一個PRG 檔）或者另一個Error 方法中沒有代碼的對
象的某個方法，當被調用代碼中出現一個錯誤時，觸發的是調用物件的代碼..即使被調用
代碼中自己有一個本地的ON Error 錯誤處理器也是這樣。這種機制存在著兩個問題：
��n許多錯誤可以預先就被估計到，例如試圖打開一個表，而這個表已經被別人獨佔使用了。然而，
由於被調用程式的ON Error 錯誤處理器不會被觸發，那麼這個程式就沒有機會去處理它自己的
錯誤。
��n由於調用物件不可能預知到被調用物件會發生什麼錯誤，除了那些一般性的處理方法（記錄下
錯誤資訊，向用戶顯示一個錯誤資訊對話方塊、然後退出等等）以外，調用物件對被調用物件中
發生的處理簡直可以說是束手無策。
很顯然，我們需要一個更好的機制。幸運的是，VFP 8 給了我們一個更好的工具：結構
化錯誤處理。
結構化錯誤處理
C++ 已經有結構化錯誤處理很長時間了。.NET 把結構化錯誤處理提供給了那些以前缺
少它的語言，例如VB.NET。那麼到底什麼是結構化錯誤處理呢？結構化錯誤處理意味著
被執行的代碼是在一個特殊的塊、或者結構中的，當這段代碼中發生任何錯誤的時候，這個
結構中的另一塊代碼會處理它。
VFP 8 通過下面的途徑實現了結構化錯誤處理：
��nTRY...ENDTRY 結構讓你可以運行可能會發生錯誤的代碼，並在這個結構中處理錯誤。這個結構
會遮罩所有其他的錯誤處理器。
��n一個新的THROW 命令讓你可以將錯誤傳遞給一個更高層次的錯誤處理器。
��n一個新的Exception 基礎類提供了一種面對物件的傳遞錯誤資訊的途徑。
TRY, TRY again
結構化錯誤處理的關鍵，是新的TRY...ENDTRY 結構。這裏是它的語法：
try
[ TryCommands ]
[ Catch [ to VarName ] [when lExpression ]
[ CatchCommands ] ]
[ exit ]
[ throw [uExpression ] ]
[ Catch [ to VarName ] [when lExpression ]
[ CatchCommands ] ]
[ exit ]
[ throw [uExpression ] ]
[ ...(其他的catch 代碼塊) ]
[ finally
[ FinallyCommands ] ]
endtry
TryCommands 表示VFP 將試著去運行的命令。如果沒有錯誤發生，接下來在可選的
FINALLY 代碼塊中代碼將會被執行（如果有FINALLY 代碼塊的話），最後執行在Endtry
之後的代碼。如果在Try 塊中發生了任何錯誤，VFP 會立即退出這塊代碼並開始執行那些
Catch 語句。
如果一個Catch 語句中有VarName，VFP 會建立一個Exception 物件，用錯誤的資訊
填充這個物件的屬性，然後把對這個物件的一個引用放到VarName 變數中去。VarName 只
可以是一個正常的變數，不能為一個物件的屬性。如果你前面聲明過這個變數，那麼這個變
量的有效範圍就是你聲明的那種（比如LOCAL）；如果你沒有聲明，那麼這個變數的有效
範圍就是PRIVATE。稍候我們將探討一下Exception 基礎類。
如果用上了可選的WHEN 子句，那麼CATCH 語句就像是CASE 語句一樣。在
WHEN 子句中的運算式返回的必須是一個邏輯值，以便VFP 能決定該怎麼辦。如果這個
運算式的結果是.T.，那麼該CATCH 語句塊就會被執行。如果為.T.，則VFP 會轉到下
一個CATCH 語句。這樣一直繼續下去直到碰到某個WHEN 運算式返回.T. 的CATCH
語句、一個沒有WHEN 子句的CATCH 語句、或者沒有別的CATCH 語句了（稍候我
會談談最後這種情況）。通常情況下，WHEN 運算式會查看一下Exception 物件的一些屬
性（例如ErrorNo，它表示錯誤號）。
一旦VFP 找到一個可用的CATCH 語句，在這一塊中的代碼就會被運行，這塊代碼
運行完畢之後，接著被運行的，是在可選的FINALLY 塊（如果有這個塊的話）中的代碼。
最後則繼續運行在ENDTRY 之後的代碼。
下麵的示例來自附帶的SimpleTry.prg 檔，它演示了CATCH 語句是怎麼被運算的、
以及TRY 結構是怎麼覆蓋ON ERROR 設置的：
on error llError = .T.
llError = .F.
try
wait window xxx
catch to loException when loException.ErrorNo = 1
wait window 'Error #1'
catch to loException when loException.ErrorNo = 2
wait window 'Error #2'
catch to loException
lnError = loException.ErrorNo
messagebox('Error #' + transform(lnError) + chr(13) + ;
'Message: ' + loException.Message)
finally
messagebox('Finally')
endtry
on error
messagebox('ON ERROR ' + iif(llError, 'caught ', ;
'did not catch ') + 'the error')
如果VFP 沒有找到一個可用的CATCH 語句，就會彈出一個“未處理的例外錯誤”（錯
誤號2059）。有許多原因你會不想讓這種情況發生，其中最大的問題是：這樣一來，原來的
錯誤就不可能解決了，因為我們手頭就只有那個“未處理的例外錯誤”的錯誤資訊了。
下面的例子演示了當有一個未處理的異常時將會發生的事情（取自
UnhandledException.prg）。當你運行這段代碼的時候，你將會看到彈出一個錯誤資訊告訴你，
這是一個未處理的異常，而不是引起這個錯誤的原因：變數XXX 不存在。
on error do ErrHandler with error(), program(), lineno()
try
wait window xxx
catch to loException when loException.ErrorNo = 1
wait window 'Error #1'
catch to loException when loException.ErrorNo = 2
wait window 'Error #2'
finally
messagebox('Finally')
endtry
on error
procedure ErrHandler(tnError, tcMethod, tnLine)
local laError[1]
aerror(laError)
messagebox('Error #' + transform(tnError) + ;
' occurred in line ' + transform(tnLine) + ' of ' + ;
tcMethod + chr(13) + 'Message: ' + message() + ;
chr(13) + 'Code: ' + message(1))
後退無門
結構化錯誤處理和其他VFP 錯誤處理方式的一個重要的區別是：你不能返回到代碼出
錯的地方。在Error 方法或者ON ERROR 常式中有幾種可以繼續的辦法：
��nReturn（或者一個沒有Return 語句的隱式Return）返回到出錯代碼的下一行。但是，由於導致
出錯的那一行代碼沒有完成自己的工作（例如初始化一個變數或者打開一個表等等），那麼這麼
做通常會導致發生其他的錯誤。
��nRetry 返回到出錯的那一行代碼。除非錯誤奇跡般的自己消失了，否則肯定會再發生同樣的錯誤。
��nQUIT 直接退出應用程式。
��nReturn To 返回到調用堆疊上的一個常式，例如一個包含著Read Events 語句的程式。如果你不
想退出應用程式，而又不願意返回到出錯的那個常式的時候，這個命令是非常有用的。當然，
這並不意味著一切OK 了，但當發生的並非是什麼災難性的錯誤的時候（例如當進入表單的時
候發生了一個簡單的資源佔用問題），它通常讓用戶可以做些什麼。
在一個TRY 結構的情況下，一旦發生了一個錯誤，那麼TRY 塊裏運行的代碼就立即
被結束，並且你再也不能返回到那裏面去。如果你在CATCH 塊中（事實上，在這種結構
的任何地方都不能用）使用了Return 或者Retry，就會發生2060 號錯誤。當然，你還是可
以用QUIT 來退出應用程式的。
用FINALLY 來擦屁股
搞清楚FINALLY 子句為什麼會重要著實花了我一點時間。畢竟，不論是否發生了錯
誤，在ENDTRY 語句後面的代碼都會被運行。不過我後來發現事情並非如此..一會兒我
討論THROW 命令的時候你就會知道了，錯誤可以被“冒泡”給下一個更高級別的錯誤處
理器，而且很有可能就不再從這個高級別的錯誤處理器中返回了。這樣的話，我們就不能保
證在ENDTRY 後面的代碼一定會被運行。我們能保證的是：在FINALLY 塊中的代碼肯
定會被運行（不過事情總是沒有絕對的..如果一個COM 物件的錯誤處理器調用了
COMReturnError()函數，就會立即返回到COM 用戶端）。
這裏是一個演示這種情況的例子（UsingFinally.prg）。對ProcessData 函數的調用被封
裝在一個TRY 結構中。ProcessData 自己也有一個TRY 結構，不過它只處理不能獨佔的打
開表錯誤。所以，WAIT WINDOW XXX 錯誤就不會被捕捉到。結果，錯誤將會被冒泡給在
主程序中的外層的TRY 結構。這樣的話，跟在ProcessData 的EndTry 語句後面的代碼就
不會被運行。如果把ProcessData 中FINALLY 塊裏的代碼給注釋掉，當程式結束時你會
看到Customers 表還打開在那裏。不注釋掉這段代碼再運行的話..你將看到這一次
Customers 表被關閉了，這樣代碼就把自己的屁股擦乾淨了。
try
do ProcessData
catch to loException
lnError = loException.ErrorNo
messagebox('Error #' + transform(lnError) + ;
' occurred.')
endtry
if used('customer')
messagebox('Customer table is still open')
else
messagebox('Customer table was closed')
endif used('customer')
close databases all
function ProcessData
try
use (_samples + 'data\customer') exclusive
* 做一些處理
wait window xxx
* 處理器不能獨佔的打開表
catch to loException when loException.ErrorNo = 1705
* 不管用什麼清理代碼
* 把這部分先注釋掉、再取消注釋，運行下看看有什麼區別
finally
if used('customer')
messagebox('Closing customer table in FINALLY...')
use
endif used('customer')
endtry
* 現在再清理是沒用的，代碼不會被運行，因為錯誤已經被冒泡出去了。
if used('customer')
messagebox('Closing customer table after ENDTRY...')
use
endif used('customer')
Exception 對象
Visual FoxPro 8.0 包含有一個新的Exception 基礎類，以為傳遞錯誤資訊提供一個面對
物件的解決方案。如你前面所見，Exception 物件是當你在CATCH 命令中使用了To
Varname 的時候被建立的。還有一種情況就是當你使用Throw 命令的時候也會建立
Exception 物件，這個稍後再說。
除了常見的那些屬性、事件、方法（Init、Destroy、BaseClass、AddProperty 等等）以
外，Exception 還有一套關於一個錯誤的資訊的屬性..如表1 所示。所有這些屬性都是運
行時可讀寫的。
屬性類型相似函數功能
Details 字元型SYS(2018) 關於錯誤的其他資訊（例如不存在的變
量或者檔的名稱等等），若沒有則為
Null
ErrorNo 數值型Error() 錯誤號
LineContents 字元型MESSAGE(1) 導致錯誤發生的那行代碼
LineNo 數值型LINENO() 行號
Message 字元型MESSAGE(1) 錯誤消息
Procedure 字元型PROGRAM() 發生錯誤的過程或者方法
StackLevel 數值型ASTACKINFO() 該過程的調用堆疊層數
UserValue 變體型沒有相應的函數在一個Throw 語句中指定的運算式
把它扔給我
結構化錯誤處理的最後一部分是新的Throw 命令。Throw 就像是原有的Error 命令.
.它把錯誤的情況傳遞給一個錯誤處理器..不過，它的工作方式是相當不同的。這裏是這
個命令的語法：
throw [uExpression]
&°uExpression&±可以是你希望的任何東西，例如一個message、一個數字、或者一個
Exception 對象。
如果指定了uExpression，THROW 會建立一個Exception 物件，並把它的ErrorNo 屬
性設置為2071、把Message 屬性設置為“User Thrown Error”、以及把UserValue 屬性設
置為uExpression。如果沒有指定uExpression，那麼若當前已有一個Exception 物件（就是
當錯誤發生的時候被Catch to 命令建立的那個），則該Exception 物件被使用；若當前沒有，
則會新建一個Exception 物件。不管是哪一種情況，接下來它會把Exception 物件傳遞給
更高一層錯誤處理器（通常指的是包含著“調用Throw 語句的當前TRY 結構”的一個TRY
結構）。這裏是TestThrow.prg 中的一個例子：
TRY
TRY
WAIT WINDOW xxx
CATCH TO loException WHEN loException.ErrorNo = 1
WAIT WINDOW &°Error #1&±
CATCH TO loException WHEN loException.ErrorNo = 2
WAIT WINDOW &°Error #2&±
CATCH TO loException
Throw loException
ENDTRY
CATCH TO loException
lnError = loException.ErrorNo
lcMessage = loException.Message
MESSAGEBOX(‘Error #’ + transform(lnError) + chr(13) + ;
‘Message: ’ + lcMessage, 0, ‘Thrown Exception’)
lnError = loException.UserValueErrorNo
lcMessage = loException.UserValueMessage
MESSAGEBOX(‘Error #’ + transform(lnError) + chr(13) + ;
‘Message: ’ + lcMessage, 0, ‘Original Exception’)
ENDTRY
** 現在再來一遍，不過Throw 語句不帶任何運算式
TRY
TRY
WAIT WINDOW xxx
CATCH TO loException WHEN loException.ErrorNo = 1
WAIT WINDOW &°Error #1&±
CATCH TO loException WHEN loException.ErrorNo = 2
WAIT WINDOW &°Error #2&±
CATCH TO loException
Throw
ENDTRY
CATCH TO loException
lnError = loException.ErrorNo
lcMessage = loException.Message
MESSAGEBOX(‘Error #’ + transform(lnError) + chr(13) + ;
‘Message: ’ + lcMessage, 0, ‘Thrown Exception’)
ENDTRY
也許你會認為上面代碼中的THROW loException 命令是把loException 擲出給上一層的
錯誤處理器，其實並非如此。THROW 擲出的是一個新建的Exception 物件，loException 則
被放在這個新Exception 物件的UserValue 屬性裏面。因此，在前一個外部TRY 結構中的代
碼表明該TRY 結構接收到的是一個用戶擲出錯誤，要獲得真正的錯誤資訊，你必須從物件
引用UserValue 來取得內部Exception 物件的屬性。
上面代碼中的第二個例子表明，如果有Exception 物件，那麼THROW 自己會去重新擲
出這個Exception。在這種情況下，外部TRY 結構獲得的與內部TRY 結構建立的是同一個
物件，所以，外部錯誤處理器不需要去引用這個物件的UserValue 屬性。
你可以在一個TRY 結構的外面使用Throw 語句，但這樣做不會帶來什麼比Error 命令
更多的好處，因為不管何種情況下，Throw 語句擲出的Exception 物件都必須要有一個能捕
捉到它的TRY 結構，若沒有的話，則VFP 的錯誤處理器會被調用。事實上，如果真的有什
麼不屬於TRY 結構的東西捕捉到了這個Exception，那才是個令人困惑的問題，因為只有
TRY 結構才能捕捉到被擲出的Exception 物件。在Error 方法或者ON ERROR 常式的情況下，
被接收的參數和AERROR()的結果所關聯的，將是Throw 語句和未處理的exception 錯誤，
而不是為什麼使用了Throw 語句的原因。Exception 物件的某些屬性將被放在由AERROR()
函數填充好了的陣列的第2 或第3 列中，以便錯誤處理器能夠分析這些列。無論如何，這都
不能算是一種處理錯誤的正確方式。所以，請保證Throw 語句被使用的時候，有一個TRY
結果能夠捕捉到它。
天堂裏的煩惱
在VFP 的錯誤處理機制中最大的問題是：怎麼在錯誤狀況下，阻止錯誤的發生。我說
“錯誤狀況”的意思指的是錯誤當前已經發生了，並且，已經被某個物件的Error 方法或者
全局ON Error 錯誤處理器設下的陷阱所捕捉到..但是，又還沒碰到一個Return 或者Retry
語句。在這個狀況中，如果出現了什麼新的錯誤，那麼就沒有什麼安全的辦法可以捕捉到這
個錯誤..通常情況下，用戶會得到一個VFP 錯誤對話方塊，帶著一個VFP 錯誤消息以及
Cancel 和Ignore 按鈕。所以說，你的整個錯誤處理機制必須是你的應用程式中Bug 最少的
部分，並且你還必須對那些並非Bug 而是由環境引起的問題進行測試。
例如，假定你的錯誤處理器會把錯誤情況記錄到一個叫做ERRORLOG.DBF 的表中。那
麼，要是這個表不存在的話該怎麼辦？
你必須用FILE()去檢查這個表是否存在，如果沒有的話就要建立這個表。
如果這個表已經被別的什麼地方的代碼獨佔的打開了呢？你可以最大限度的減少獨佔
打開該表的機會，以減少錯誤發生的機會，但是，要做到絕對的安全的話，你應該先用一下
FOPEN()試試能否打開它，因為FOPEN()如果不能打開的話會返回一個錯誤代碼而不是導致
發生一個錯誤。
如果Errorlog.dbf 檔存在，並且也可以用FOPEN()來打開它..但是檔已經被損壞
了怎麼辦呢？糟糕的是沒有測試這個問題的好辦法。
看到問題所在了吧？為了要對付可能出錯的每件事情，你的錯誤處理器的代碼會變得相
當的複雜..糟糕的是，這麼複雜的代碼肯定會出現不少新的Bug。
在VFP 以前的版本中沒有解決這個問題的辦法。你只能寫下合理的代碼、盡可能多的
測試它，然後就只能求老天保佑了。幸運的是，在VFP8 中終於有了解決的辦法：把你的錯
誤處理器封裝在一個TRY 結構中。由於任何發生在TRY 塊中的錯誤都會被CATCH 捕捉到，
所以現在我們的錯誤處理代碼終於有了一個安全網了。
這裏是一個簡單的例子（下載檔中的WrappedErrorHandler.prg）：
On Error do ErrorHandler with error(), program(), lineno()
Use MyBadTableName && 這個表並不存在
On Error
Procedure ErrorHandler(tnError, tcMethod, tnLine)
Try
Use ErrorLog
Insert into ErrorLog Values (tnError, tcMethod, tnLine)
Use
** 在這個錯誤處理器中會忽略任何問題
CATCH
ENDTRY
Return
EndProc
如果ErrorLog 表由於檔不存在、表無法打開、檔內容損壞或者任何其他原因導致
不能使用，CATCH 塊都將會被運行。在這個例子裏，由於CATCH 塊中沒有打開，所以在
錯誤中的所有錯誤都被忽略了。
錯誤處理策略
現在我們來總結一下，並探討一個整體的錯誤處理策略。這裏是我目前使用的辦法：
��n使用三個錯誤處理層：TRY 結構對付本地錯誤；Error 方法用作可以被封裝的物件
層次的錯誤處理器；而ON Error 命令則負責全局的錯誤處理。在前面的兩層中處
理那些預料到的錯誤，而把未預料到的錯誤傳遞給下一層。
��n把錯誤處理器封裝在一個TRY 結構中，以防止當錯誤處理代碼本身出現錯誤時會
彈出的VFP 錯誤處理對話方塊的出現。
��n為你的錯誤處理機制使用責任鏈設計模型。這個問題請參見Foxtalk 1998 年第1 期
上我的專欄文章《再論錯誤處理》（ Error Handling Resitied ）、或者在
www.stonefield.com 上關於錯誤處理的白皮書。
��n不要使用一個TRY 結構來封裝你的整個應用程式。如果這樣做的話，一旦任何錯
誤發生，就沒辦法留在程式的內部觀察錯誤的資訊了。
��n除非有一個TRY 結構，否則不要使用Throw 語句。
總結
在VFP8 中新增的結構化錯誤處理功能為我們提供了三個錯誤處理器的層次：本地的、
物件的、還有全局的。結構化錯誤處理讓你可以減少傳遞錯誤資訊的代碼數量，使你的應用
程式變得簡單、可讀性更好、並且更容易維護。此外，某些棘手的錯誤..例如一個物件漫
不經心的去捕捉發生在另一個物件中的錯誤這種情況..現在可以更明快的被處理了。我建
議你花些時間好好的玩轉它，並考慮將它引入為你的整個錯誤處理策略的一個關鍵部分。