VFP 愛用者社區

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

Visual FoxPro 中的錯誤處理

作者：Doug Hennig
翻譯：RMH

簡介
與FoxPro 2.x相比，Visual FoxPro對錯誤的處理更為靈活但也更為複雜。當物件具有Error方法來處理局部錯誤時，怎樣為你的應用程式提供公共的、全局錯誤處理服務?當發生錯誤時如何恢復?這裏提供一種經證明是行之有效的方法來實現Visual FoxPro應用程式的錯誤處理 – 開始於單獨的控制項，結束於一個全局的錯誤處理物件。
錯誤處理基礎
在錯誤處理中有許多困難的問題：設置錯誤處理器，檢查錯誤的情況，提示用戶發生了什麼情況(並可能將其寫入一個檔供以後分析)，並解決問題(試著再次執行命令，繼續出錯的語句的下一條語句，退出系統等等)。
設置錯誤處理
與FoxPro 2.x中的設置錯誤處理相同，VFP中要設置全局錯誤處理仍然使用on error命令。舉例如下：

on error do ERR_PROC with error()， sys(16)， lineno()

這些參數告訴錯誤處理程式：錯誤號，發生錯誤的程式的名字，行號。你可以按你的需要傳遞任意參數到錯誤處理程式。
VFP以各物件的ERROR事件的方式，提供了對全局錯誤處理的能力。在VFP中每一個物件的事件模組都具有Error事件。當然，並非每一個物件都有Error方法。如果你不清楚這種差別，記住，事件是被用戶或系統的某些動作觸發的(擊鍵，滑鼠單擊，或者一些Visual FoxPro認為是錯誤的東西)，當事件發生時方法編碼被執行。當一個消息傳遞到一個物件通知它執行方法時，方法代碼也會被執行。在很多事件中，如滑鼠單擊，如果物件的方法中沒有代碼，事件被忽略或執行默認的動作。可是，當錯誤出現時，將會發生什麼取決於一系列的事情。
當一個物件調用另一物件或一個非物件程式(如PRG檔)時出現錯誤、且該物件存在Error方法時，物件的Error方法將被調用。如果該物件沒有Error方法將會發生什麼情況呢?當我第一次使用VFP時，我假設該物件的父容器(如Form)的Error方法將被調用。然而，情況並非如此。實際情況是，如果任何在調用堆疊上的物件存在著Error方法，該方法將被調用;如果沒有，on error常式(如果有的話)被調用。如果沒有on error常式，Visual FoxPro執行它自己的錯誤處理(就是那個聲名狼籍的取消/忽略對話方塊)，然後程式崩潰。
檢查錯誤情況
FoxPro 2.x中的一系列的函數和VFP都有助於檢查錯誤發生的原因，包括error()，message()，lineno()，sys(16)，和sys(2018)。VFP還提供一個aerror()函數，用於提供最近發生的錯誤的資訊並將這些資訊存入一個陣列。雖然該陣列中的一些資訊也可從其他函數獲得，對於某些類型的錯誤(如OLE，OBDC，和觸發器)，aerror()其他函數則不能得到錯誤資訊(例如何種觸發器造成了錯誤)。
提示用戶發生了什麼
坦率地告訴用戶發生了錯誤，並允許用戶決定如何處理錯誤。主要涉及到要告訴用戶什麼、並提供給用戶什麼樣的選擇。對要顯示的錯誤資訊進行適當修改，並以盡可能平靜的方式措詞，以防止驚慌失措的用戶同時按下“Ctrl-Alt-Delete”。它也應提供如何處理錯誤的資訊。例如，一些簡單的錯誤如印表機未聯接可以詢問用戶確信印表機正確地聯接並裝好了紙。這樣用戶可以在列印和取消列印之間作出選擇。如果一個用戶試圖修改一個被別的用戶鎖定的記錄，你可以告訴用戶當前正有另一用戶在修改該記錄，並給出再試一次或取消修改的選擇。
在VFP中可能出現的錯誤多達600種以上，你可能會令人心悸地想為每一個錯誤給出有意義的資訊。幸運的是，如果你查看VFP的幫助中關於錯誤資訊的主題，你會發現它們中的大多數僅歸類於下列少數的種類：
• 決不會發生
• 如果程式師在寫程式前未喝酒，就不會發生
• 一個以上的用戶同時使用該系統時會發生
• 需要個別處理的錯誤
在第一種類別中，你的程式除了退出之外沒有別的選擇。第二種錯誤可以在測試中被發現，但若未發現，你的應用程式將報告並登錄該錯誤，然後關閉。第三種類型的錯誤也可以在測試中被發現，但是僅出現一個簡單的類似於“你現在不能操作”的錯誤資訊。真正需要你處理的只是第四種類型的錯誤。這種類型錯誤的例子是欄位或表驗證規則失敗，主關鍵字失敗(如果你使用了系統指定的代理關鍵字，這種情況很少發生)，觸發器失敗，和檔未找到。
在顯示錯誤資訊給用戶之前，許多開發者喜歡登錄錯誤到一個錯誤登錄檔。這已被證明了是極有價值的，因為用戶常常會含糊的向你報告錯誤發生的細節。錯誤登錄檔可以是一個文字檔案，但是我使用一個表中的欄位來保存錯誤發生的日期和時間(可以是VFP中的DateTime欄位)，用戶名，錯誤號和資訊，行號和錯誤出現處的代碼，一個備註型欄位用於包含當前的記憶體變數。
解決錯誤
解決錯誤是複雜的事情。retry命令試著再次執行發生錯誤的命令，但是對於很多錯誤而言，由於用戶自己處理錯誤的能力所限，該命令對用戶處理錯誤沒有多大幫助。return則繼續執行發生錯誤的命令的後面一行程式，但由於造成錯誤的程式列並沒有執行，所以因此而造成的二級錯誤資訊可能會接踵而至，如變數沒有建立(畢竟，如果可以忽略造成錯誤的程式且不會帶來任何問題的話，它是做什麼用的呢?)。cancel不是一種現實的選擇，因為它終止應用程式，這樣就沒有機會來適當地進行退出前的系統清理。以被約束的方式關閉應用程式是一個正確的選項，因為很多錯誤是由於編程人員或作業系統造成的，在問題被解決前沒有更多的選擇。作為一個開發者，你可能也願意選擇取消應用程式並返回到命令視窗。這樣做的代碼將盡可能地清除環境。
另一個選項是使用return to master或return to 來退出發生錯誤的程式而返回到主控程式或指定的程式。要小心處理這種選項，因為這樣會使系統進入一種混亂狀態：表單和視窗仍然存在，表或游標任然是打開的，等等。在使用return to命令前，盡可能地清除這些東西是一個好的辦法。
設計錯誤處理方案
全局Error 處理和物件的Error方法代表了一個事物的兩個方面：
• 當Error方法是造成錯誤的物件的一部分時，全局錯誤處理器與發生錯誤的根源相距較遠。這樣，Error方法知道它自己所處的環境，那些錯誤可能會發生，如何解決錯誤。例如，CommonDialogs ActiveX控制項(顯示檔，列印，色彩和印表機的對話方塊)在用戶選擇取消時，將會造致錯誤。它會無聲地讓全局錯誤處理器處理錯誤，由於它只知道那是一個某種類型的OLE錯誤並不知道怎樣去處理它。只能在CommonDialogs控制項的Error方法中放入代碼來處理用戶選擇取消的情況。
• 全局錯誤處理器在VFP的事件處理器之外，用FoxPro的老的“ON”事件方法進行調用(該方案仍被用於功能表和on key label命令)。這意味著，你不能使用象Thisform一樣的物件語法，或發佈象private datasessions這樣的會使錯誤處理變得複雜的命令。
• 全局錯誤處理器可以有效的把錯誤處理服務放入同一個地方(如錯誤登錄和顯示)。但在你的應用程式中的每一個物件的Error方法中，它處理多種不可預期的錯誤時確是低效率的(如網路連接斷線)。
讓我們看看設計一個將兩個世界進行最好的一體化的錯誤處理方案。我們希望以盡可能有效的方式處理錯誤，同時還提供個別物件處理它們自己特殊錯誤的能力。這裏是我們使用的策略：
• 就象一個玩笑中所說的那樣，一個物件比其父類更清楚它正在做什麼，因此一個物件的Error方法將處理它自己所能處理的一切錯誤。並將它所不能處理的部分用dodefault()命令傳遞給它的父類。在該類層次中的各個子類都這樣做。如果一個子類或一個類的實例不需要處理任何特殊的錯誤，則其Error方法中不會放置任何代碼，以促成其父類代碼自動執行。這樣，SFDeepSubClassTextBox.Error調用SFSubClassTextBox.Error再調用SFTextBox.Error。
• 物件的最頂層父類的Error方法將處理任何它能處理的錯誤。它用This.Parent.Error傳遞那些經不能處理錯誤到它的容器。
• 由於容器類與控制項一樣工作(它們傳遞不可處理的錯誤到它們的父類，最頂層父類傳遞錯誤到它們的容器類)，實際效果是我們上移一個類層次而進入到容器類的錯誤處理器。
• 最頂層父類的最外部容器的Error方法將處理它可處理的任何錯誤。它會傳遞那些它不能處理的錯誤到全局錯誤處理器。
以下是一個設計流程圖：在鏈中的每一個物件處理錯誤或將它傳遞到鏈中的下一個物件。在這個多層方案中，當你從物件到全局錯誤處理器時，錯誤處理獲取較少的細節和較多的一般資訊，允許錯誤在各個不同等級進行處理。圖 1 表明了這種策略。

圖 1. 錯誤處理策略。
我們在應用程式啟動時從SFErrorMgr實例化一個物件到一個總體變數oError。它的一個方法(ErrorHandler)既可以象上述一樣被物件直接調用也可以用on error命令調用。錯誤處理物件有一個簡單的介面(對編程而言)，因此SFErrorMgr接受與Error方法相同的參數(錯誤號，方法名，行號)並返回一個說明用戶選擇的串給用戶(或物件)以便處理錯誤。錯誤物件處於處理鏈的末端，因此它不知道調用它的地方的環境(可能經歷了一系列的傳遞，在不同的資料工作期中等)。作為一個結果，它不能真正地作更多的“處理”(應該是：解決)。它的用途是顯示一資訊給用戶，登錄錯誤以備後用，並決定下一步的行動(在可靠的可預知條件下)或更多的，可靠的，將怎樣做的詢問。這樣，錯誤處理物件將真正地用於處理你沒有預料到的可預知的錯誤(一但它們出現，你會修改造成錯誤的物件，類，或過程)和不可預知錯誤(真正的bugs或未預料的環境條件)。
全局錯誤處理器自己會作出一個全局性的決定(調出VFP的Debugger或關閉應用程式)或允許物件引發錯誤來作出最後的決定。要允許後者，在錯誤處理鏈中的每一步返回一個決定碼到上一級。為簡便起見，我決定返回一個串來說明用戶選擇了那一決定：“重試”重新執行引起錯誤的命令，“繼續”則從引發錯誤的程式的下一行繼續運行程式，或“關閉表單”用於關閉當前起控制作用的表單。各物件依返回的資訊執行相應的行動。由於容器類的Error方法可能已經被其成員物件或它自己的某個方法調用，容器類必須決定是向上傳遞返回資訊還是由它自己處理。在稍後，我們將會看見這些代碼。
該方案有一個問題：控制項置於VFP的Page，Column，或其他沒有Error方法代碼的容器基類上時，由於它們調用一個空的方法，所以它們實質上沒有錯誤捕捉!解決辦法是在類層次中向上移動直到找到一個具有Error方法代碼的父類。如果我們不能找到這樣的父類，則顯示一個一般性的錯誤資訊(這並不可靠，由於所有的表單類都是以SFForm類為基類，而SFForm沒有Error方法代碼)。
要注意的事是完整的錯誤處理鏈必須是你的應用程式中最沒有Bug的(經徹底調試的)部份，因為在錯誤狀態下再次出現錯誤時，唯一可依靠的就是取消/忽略對話方塊了。幸運的是，由於你可以將錯誤處理代碼放入你的大多數工作框架中，一但你使它們工作，它們不會受到更多的關注(雖然與眾不同的環境條件仍會使錯誤處理器自身失敗)。不要試著在錯誤處理物件中建立一個錯誤處理方法：當錯誤處理器自身出錯時，它不會被調用。
Error方法
讓我們注意錯誤處理策略的更多的細節。當一個物件發生錯誤時開始點是在該物件所具有的Error方法，因此我們從這裏開始。
在我的應用程式的基類中，大多數類的Error方法代碼，包含在SFCTRLS.VCX中，清單如下(包括ccMSG_RETRY定義在ERRORS.H中，包含於SFCTRLS.H中，每一個類的include檔)。我說“大多數類”，是因為頂級容器如form和toolbar的工作方式有一小點不同。這是我的少數的希望VFP支持多重繼承的理由之一;在這和情況下，你需要象在VB中那樣，將相同的代碼放入所有類的Error方法中(採用複製-粘貼的方法)。

lparameters tnError，
tcMethod，
tnLine
local loParent，
lcMethod，
lcReturn，
lcError

* 向上移動一個層次直到我們找到一個具有Error 方法的父類

if type('Thisform') = 'O'
loParent = iif(pemstatus(Thisform， 'FindErrorHandler'，
5)， Thisform.FindErrorHandler(This)， .NULL.)
else
loParent = .NULL.
endif type('Thisform') = 'O'
lcMethod = This.Name + '.' + tcMethod
do case

* 我們有一個可以處理錯誤的父類。

case not isnull(loParent)
lcReturn = loParent.Error(tnError， lcMethod， tnLine)

* 我們有一個錯誤處理物件，因此調用它的 ErrorHandler()方法。

case type('oError') = 'O' and not isnull(oError)
lcReturn = oError.ErrorHandler(tnError， lcMethod，
tnLine)

* 一個全局錯誤處理器在起作用，因此讓我們傳遞錯誤資訊給它。
* 以適當的值替換可靠的參數以傳遞到錯誤處理器(程式名，錯誤號以及行號)。

case not empty(on('ERROR'))
lcError = strtran(strtran(strtran(strtran(upper(on('ERROR'))，
'SYS(16)'， lcMethod)，
'PROGRAM()'， lcMethod)，
'ERROR()'， 'tnError')，
'LINENO()'， 'tnLine')

* 如果錯誤處理器是以 DO 命令調用，進行宏擴展並假設返回值是"繼續"。如果錯誤處理器是
* 被一個函數調用 (比如一個物件的方法)，調用它並獲得返回值。

if left(lcError， 3) = 'DO '
&lcError
lcReturn = ccMSG_CONTINUE
else
lcReturn = &lcError
endif left(lcError， 3) = 'DO '

* 顯示一個一般的對話方塊。

otherwise
messagebox('錯誤號' + ltrim(str(tnError)) +
'對象 ' + This.Name +
'方法 '+ tcMethod +
'行號 '+ ltrim(str(tnLine))， 0，
_VFP.Caption)
endcase

* 確信返回資訊是可接受的。否則，假定為
* "繼續"。

lcReturn = iif(type('lcReturn') <> 'C' or
empty(lcReturn) or not lcReturn $ ccMSG_CONTINUE +
ccMSG_RETRY + ccMSG_CANCEL， ccMSG_CONTINUE， lcReturn)

* 處理返回值。

do case
case '.' $ tcMethod
return lcReturn
case lcReturn = ccMSG_RETRY
retry
case lcReturn = ccMSG_CANCEL
cancel
otherwise
return
endcase
以上代碼檢查表單控制項是否具有FindErrorHandler方法，如果有，調用它來定位到控制項的第一個父容器(不要被這個代碼迷惑;你可以在供提供的源代碼中查看它們)。這樣做防止了這樣一種情形：由於Page，Column，或其他容器類沒有Error方法代碼而致使錯誤停留在這些類中。如果一個可進行錯誤處理的父容器找到了，它的Error方法以相同的參數被調用，除非物件的名字被加到了tcMethod，因此我們的錯誤處理服務程式能夠知道錯誤是發生在那一物件。如果父容器未找到但存在一個全局錯誤處理器(稍後我們再談全局錯誤處理程式)，它的ErrorHandler方法被調用。如果一個ON ERROR常式存在，我們將調用它(首先將我們知道的值調整為它可接受的參數)，無論它是一個函數還是一個過程。如果我們沒有東西可傳遞，就使用messagebox()來顯示一條資訊。
錯誤處理器返回的值將決定怎樣處理錯誤。首先，如果該錯誤不是發生在本地，我們必須返回決定資訊而不是自行處理。我們將用檢查發生錯誤的方法的名字的句點號(.)來檢查這一點;如果錯誤出現在一個類的方法中，VFP只傳遞方法名，但物件成員傳遞物件和方法名，這就提供了一種快速的方法用物件自己或物件名來區別錯誤原因。如果不是這種情況，則是我們的錯誤，因此我們將‘重試’，‘取消’，或‘返回’。
由於它們是“頂級”容器(我沒有使用表單集Formsets)，SFForm和SFToolbar類的Error方法與其他物件不同。該方法使用自定義的SetError方法來組織一些自定義屬性形成關於錯誤的資訊，並且用HandleError方法來處理錯誤。最後它處理返回值，它自己要麼執行一個行動(比如關閉表單)要麼返回到調用這個方法的物件。注意如果物件是DataEnvironment且它自己替換處理這些錯誤，它將不返回值。你可能想改變這一行為。同時也應注意使用return to;稍後我們將討論這一問題的更多細節。

lparameters tnError，
tcMethod，
tnLine
local lcReturn，
lcReturnToOnCancel

* 使用 SetError() 和 HandleError() 來取得錯誤資訊並處理它。

with This
.SetError(tnError， tcMethod， tnLine)
lcReturn = .HandleError()

* 如果用戶選擇了”取消”，指明到那裏去。

do case
case type('oError') = 'O' and not isnull(oError)
lcReturnToOnCancel = oError.cReturnToOnCancel
case type('.oError') = 'O' and not
isnull(.oError)
lcReturnToOnCancel = .oError.cReturnToOnCancel
otherwise
lcReturnToOnCancel = 'MASTER'
endcase
endwith

* 處理返回值，取決於錯誤是 "ours" 或來自一個成員.

do case
case lcReturn = ccMSG_CLOSEFORM
This.Release()
return to &lcReturnToOnCancel
case '.' $ tcMethod and
not 'DATAENVIRONMENT' $ upper(tcMethod)
return lcReturn
case lcReturn = ccMSG_RETRY
retry
case lcReturn = ccMSG_CANCEL
return to &lcReturnToOnCancel
otherwise
return
endcase
我們不能僅著眼於SetError 方法(你可以在提供的源代碼中自己檢驗這一點) 但以下是HandleError 方法代碼：
local lnError，
lcMethod，
lnLine，
loError，
lcMessage，
lcReturn
with This
lnError = .aErrorInfo[.nLastError， cnAERR_NUMBER]
lcMethod = .Name + '.' +
.aErrorInfo[.nLastError， cnAERR_METHOD]
lnLine = .aErrorInfo[.nLastError， cnAERR_LINE]

* 如果存在著錯誤處理物件，取得一個引用到我們的錯誤處理物件。
* 它可能是表單號也可能是一個全局物件。

do case
case type('.oError') = 'O' and not isnull(.oError)
loError = .oError
case type('oError') = 'O' and not isnull(oError)
loError = oError
otherwise
loError = .NULL.
endcase
lcMessage = ccMSG_ERROR_NUM + ltrim(str(lnError)) +
ccCR + ccMSG_MESSAGE +
.aErrorInfo[.nLastError， cnAERR_MESSAGE] + ccCR +
iif(empty(.aErrorInfo[.nLastError， cnAERR_SOURCE])，
''， ccMSG_CODE +
.aErrorInfo[.nLastError， cnAERR_SOURCE] + ccCR) +
iif(lnLine = 0， ''， ccMSG_LINE_NUM +
ltrim(str(lnLine)) + ccCR) + ccMSG_METHOD + lcMethod
do case

* 存在著一個錯誤處理物件，因此調用它的
* ErrorHandler() 方法。

case not isnull(loError)
lcReturn = loError.ErrorHandler(lnError， lcMethod，
lnLine)

* 一個全局錯誤處理程式正在起作用，因此我們將錯誤傳遞給它。以適當的
* 值為錯誤處理程式替換可靠的參數(程式名，錯誤號，和行號)。

case not empty(on('ERROR'))
lcError = strtran(strtran(strtran(strtran(upper(on('ERROR'))，
'SYS(16)'， lcMethod)，
'PROGRAM()'， lcMethod)，
'ERROR()'， 'tnError')，
'LINENO()'， 'tnLine')

* If the error handler is called with DO， macro expand it
* and assume the return value is "CONTINUE"。If the error
* handler is called as a function (such as an object
* method)， call it and grab the return value if there is
* one。

if left(lcError， 3) = 'DO '
&lcError
lcReturn = ccMSG_CONTINUE
else
lcReturn = &lcError
endif left(lcError， 3) = 'DO '

* We don't have an error handling object， so display a
* dialog box。

otherwise
lcReturn = iif(messagebox(lcMessage，
MB_ICONEXCLAMATION + MB_OKCANCEL，
_screen.Caption) = IDCANCEL， ccMSG_CANCEL，
ccMSG_CONTINUE)
endcase
endwith
lcReturn = iif(type('lcReturn') <> 'C' or empty(lcReturn) or
not lcReturn $ ccMSG_CONTINUE + ccMSG_RETRY + ccMSG_CANCEL +
ccMSG_CLOSEFORM， ccMSG_CONTINUE， lcReturn)
return lcReturn

HandleError試著通過一個全局錯誤變數oError或表單的oError屬性傳遞錯誤到全局錯誤處理物件。該方案允許你在可能的情況下，擁有一個定制版本的與表單關聯的全局錯誤處理器。如果一個ON ERROR常式存在，我們調用它(首先將我們知道的值調整為它可接受的參數)，無論它是一個函數還是一個過程。如果我們沒有東西可傳遞，就使用messagebox()來顯示一條資訊。然後從錯誤處理器返回的值回傳到Error方法。
全局錯誤處理
SFErrorMgr是一個派生於SFCustom的非可視類。它包含在SFMGRS.VCX中並使用SFERRORMGR.H包含文件中定義的一些常量。在應用程式啟動時，它被實例進總體變數oError中(參見SYSMAIN.PRG)。我們不必查看該類的全部源代碼，只需查看對我們的錯誤處理方案有關的方法代碼。你自己可已查看任何其他的方法。
Init方法接受三個參數：當錯誤出現時顯示給用戶的對話方塊的標題(保存於cTitle屬性中)，一個指明Init是否將保存當前的on error處理器並改變它到它自己的ErrorHandler方法，以及類實例化為物件時的名稱(這對於on error命令是必需的，因為我們不能使用類名詞This)。
一般說來，Destroy方法會清除已被類改變了的東西;在這種情況下，它重置VFP的錯誤處理程式到物件被實例化以前。
ErrorHandler方法被錯誤處理鏈中最後的物件直接調用，並由於它也是on error錯誤處理器故也被間接調用。以下是該方法的代碼：
lparameters tnError，
tcMethod，
tnLine
local lcCurrTalk，
lcChoice，
lcProgram
with This

* Ensure TALK is off。

if set('TALK') = 'ON'
set talk off
lcCurrTalk = 'ON'
else
lcCurrTalk = 'OFF'
endif set('TALK') = 'ON'

* Put the error into the aErrorInfo array and set the
* lErrorOccurred flag。

.GetErrorInfo(tcMethod， tnLine)

* If errors aren't being suppressed， display the error
* and get the user's choice of action。

lcChoice = ccMSG_CONTINUE
if not .lSuppressErrors

* Log the error if necessary。

if .lLogErrors
.LogError()
endif .lLogErrors

* Display the error and get the user's choice if desired。

if .lDisplayErrors
lcChoice = .DisplayError()
do case

* Cancel or Quit in development environment： remove any
* WAIT window， revert all open cursors and issue a CLEAR
* EVENTS (in the case of Quit)， and then return to the
* top-level program。

case lcChoice = ccMSG_CANCEL or
(lcChoice = ccMSG_QUIT and version(2) <> 0)
wait clear
if lcChoice = ccMSG_QUIT
.lQuit = .T.
.RevertAllTables()
clear events
endif lcChoice = ccMSG_QUIT
lcProgram = .cReturnToOnCancel
return to &lcProgram

* Display the debugger (development environment)： activate
* the Trace and Debug windows。

case lcChoice = ccMSG_DEBUG and version(2) <> 0
activate window debug
set step on

* Retry programmatic code： we must do the retry here，
* since nothing will receive the RETRY message (as is the
* case with an object)。

case lcChoice = ccMSG_RETRY
lcMethod = upper(tcMethod)
if at('.'， lcMethod) = 0 or
inlist(right(lcMethod， 4)， '.FXP'， '.PRG'，
'.MPR'， '.MPX')
if lcCurrTalk = 'ON'
set talk on
endif lcCurrTalk = 'ON'
retry
endif at('.'， lcMethod) = 0 ...

* Quit： revert all open cursors， then quit。

case lcChoice = ccMSG_QUIT
.lQuit = .T.
.RevertAllTables()
on shutdown
quit
endcase
endif .lDisplayErrors
endif not .lSuppressErrors

* Restore TALK。

if lcCurrTalk = 'ON'
set talk on
endif lcCurrTalk = 'ON'
endwith
return lcChoice
當錯誤發生時，三個參數傳遞到ErrorHandler：錯誤號，發生錯誤的程式名，發生錯誤的行號。ErrorHandler使用GetErrorInfo方法來設置lErrorOccurred屬性為.T.並設置關於錯誤的資訊到aErrorInfo屬性。如果lSuppressErrors屬性值為.T.，不登錄錯誤且不顯示錯誤資訊(這用於當你想捕捉錯誤，但又不想登錄和顯示錯誤資訊給用戶時)。否則，LogError方法被調用來登錄錯誤並且DisplayError方法用於顯示關於錯誤的資訊並取得用戶的選擇。這些選擇是：
• 調試：該選項僅當lShowDebug設置為.T.且我們是運行于VFP的開發版中時可選，調出跟蹤和調試視窗。僅當開發者使用時，lShowDebug被設置為.T.(這一點可以在用戶表中或Windows註冊表中檢查到)。
• 繼續：返回到造成錯誤的程式的後面一行，並繼續執行程式。
• 重試：重新執行出錯的程式。這裏使用了一小點技巧：如果ErrorHandler已經被明確地調用了(就是說，從一個物件的Error方法)，則不能直接發佈retry命令，由於那樣做會把控制返回到調用它的方法，而不是造成錯誤的方法。在這種情況下，我們將僅返回一個資訊“重試”。然而，如果錯誤出現在程式檔中(PRG或MPR檔中)，ErrorHandler將以on error方法被調用，因此只返回該資訊還不夠。在這種情況下，ErrorHandler必須自己直接發佈retry命令。
• 取消：在CompuServe上，一個常見的問題是：如何避免程式或方法中的其餘代碼在執行時造成錯誤?你不能使用cancel，因為那樣取消了整個應用程式。return返回到同一方法中因此那樣做並無好處。解決辦法是返回到到你的應用程式的read events語句所在的程式(在一般情況下，當你的方法代碼尚未執行時，你就發佈了該命令)。由於該過程可能不是你的應用程式的第一個執行的程式，我們將控制返回到屬性cReturnToOnCancel中指定的程式中要比使用return to master要好。當你實例化SFErrorMgr時，你可以適當的設置該屬性的值(你可以設置它的值為“MASTER”如果應用程式的第一個過程包含了read events)。如果你的read events語句是在一個物件的方法中，設置為該物件的名字;例如，如果你的read events語句是在oApp.EventHandler中，把“EventHander”放入cReturnToOnCancel屬性中。
• 退出：退出應用程式。根據我們是否使用的是VFP的開發版，而可能不同的需求。在開發模式下，當你不得不重新啟動VFP時每一次都得到一條錯誤資訊無疑是一件痛苦的事情，因此在那種情況下，這一選項將是clear events並返回到主程序，因此應用程式能夠以有序的方式關閉並返回命令視窗。如果這是一個VFP的運行時版本，我們將只清理並退出。在上述兩種情況中，在所有的資料工作期的所有游標上，我們都有將使用自定義的RevertTables方法來執行一個tablerevert(.T.)。因此，以這種方法退出，我們不會得到一個附加的錯誤(比如那個臭名遠揚的“uncommitted changes”錯誤)。
處理特殊的錯誤
到目前為止，我們已經討論了關於錯誤處理方案的一般性的問題：每一個錯誤都會造致“取消，繼續，重試，退出”對話方塊的出現。這對於可預知的錯誤是不適當的，它僅適用於不可預知性的錯誤。可預知的錯誤將在可能造致錯誤的物件的Error方法中處理。
作為處理特殊錯誤的一個例子，我們將考慮看一看SFMaintForm類(在SFFORMS.VCX中)，這是一個特別為資料登錄表單設計的SFForm類的一個子類。這是一個關於一個物件如何處理環境和可預知錯誤的好例子。
由於SFForm的Error方法以簡單的傳遞錯誤到SFErrorMgr的ErrorHandler方式調用HandleError方法，我們將不考慮用SFMaintForm中的HandleError來處理特殊的基於資料的錯誤。以下是HandleError的代碼：

local lnError，
lcMethod，
lcReturn，
loObject
with This

* Get the error number and method。

lnError = .aErrorInfo[.nLastError， cnAERR_NUMBER]
lcMethod = upper(.aErrorInfo[.nLastError，
cnAERR_METHOD])
do case

* Handle "DataEnvironment already unloaded" by not
* displaying anything。

case lnError = cnERR_DE_UNLOADED
lcReturn = ccMSG_CONTINUE

* Handle a problem in the DataEnvironment。

case 'DATAENVIRONMENT' $ lcMethod
lcReturn = .ErrDataEnvironment(lnError)

* Handle a trigger failed。

case lnError = cnERR_TRIGGER_FAILED
lcReturn = .ErrTriggerFailed()

* Handle a field rule failed by calling
* ErrFieldRuleFailed()。If it returns an object
* reference， we'll set focus to that object so the
* user can correct the problem。

case lnError = cnERR_FIELD_RULE_FAILED
loObject = .ErrFieldRuleFailed()
if not isnull(loObject)
.ActivateObjectPage(loObject)
loObject.SetFocus()
endif not isnull(loObject)
lcReturn = ccMSG_CONTINUE

* Handle a table rule failed。

case lnError = cnERR_TABLE_RULE_FAILED
lcReturn = .ErrTableRuleFailed()

* Handle a primary/candidate index violation。

case lnError = cnERR_DUPLKEY
lcReturn = .ErrDuplicatekey()

* Handle the case where someone else has the record
* locked。

case lnError = cnERR_RECINUSE
lcReturn = .ErrRecordInUse()

* Handle the case where the record was modified by
* another user during a delete。

case lnError = cnERR_RECMODIFIED and
lcMethod = 'DeleteRecord'
messagebox(ccERR_REC_MODIFIED， MB_ICONSTOP，
_screen.Caption)
.Refresh()
lcReturn = ccMSG_CONTINUE

* Handle the case where the record was modified by
* another user during an edit。

case lnError = cnERR_RECMODIFIED
lcReturn = .ErrRecChangedByAnother()

* Otherwise use the default error handler。

otherwise
lcReturn = dodefault()
endcase
endwith
return lcReturn
你可能會認為，一個處理特殊錯誤的副程式將可能由一組case語句組成，以處理所有可預知的錯誤和一個otherwise語句傳遞所有不可處理的錯誤到SFErrorMgr。在SFMaintForm的情況中，我們將處理以下錯誤：
• DataEnvironment錯誤或觸發器錯誤或欄位規則失敗：在這裏，我們將注意這些錯誤的更多細節。
• 表規則失敗，基本/候選索引違反，或其他人鎖住了記錄：其他的在系統設計時應考慮的問題(例如使用系統指定的關鍵字和使用樂觀或悲觀鎖)，關於這些，我們沒有更多的選擇;只能提交給用戶，由用戶處理這些問題。因此我們只調用特定的方法顯示適當的資訊給用戶即可。
• 當我們試著刪除一個記錄時，它已被其他用戶修改了：我們將顯示一條資訊給用戶並重新顯示表單內容為修改後的內容。
• 當我們想修改一條記錄時，它已被其他用戶修改了：我們將使用解決衝突的代碼來解決這種問題(在這裏，我們不再列出這些代碼;你可以自己查看ErrRecChangedByAnother方法中的代碼)。
當然，這不是全部的可捕捉的錯誤，但是一個好的典型例子。
資料環境
儘管DataEnvironment有自己的Error方法，但類沒有DE，因此我們必須人為的放置代碼到我們所建立的每一個資料表單的DataEnvironment.Error中。有趣的是，如果DE的Error方法中沒有代碼，它將自動調用其表單的Error方法。這樣我們將在SFMaintForm的ErrDataEnvironment方法中處理DE的錯誤。這些處理包括了“表或資料庫未找到”，“表訪問拒絕”，“表在使用中”，和“主關鍵字無效”等錯誤。在一般情況下，除了顯示錯誤資訊和關閉表單外我們沒有別的選擇。然而，我們還希望得到一些錯誤處理服務，因此我們在設置了lDisplayErrors屬性為.F.後，調用oError.ErrorHandler。這會使錯誤被登錄但不顯示錯誤資訊。我們將會在運行“關閉表單”前顯示我們自己的錯誤資訊。
要注意的一點是“DataEnvironment already unloaded”錯誤。這是由於早期的錯誤而使表單已關閉，因此當我們接收到該資訊時什麼也不必做。
觸發
如果觸發器失敗，致使觸發器失敗的物件的Error方法被啟動，而不是被觸發器(RIError procedure)設置的on error副程式。這是一個大問題：RIError設置公共變數pnError為一個非零的值，這是一個被其他常式使用的，以便知道觸發器已經失敗的變數。設想以下情形：用戶在一個表單中做了某些事情，比如刪除一個記錄使觸發器失敗而致使錯誤處理程式被調用，但由於觸發器是在一個物件的Error方法中被引發，該方法被調用要比調用保存在資料庫中的RIError常式要好。當Error方法被執行時，執行返回到觸發器。但是，由於pnError的值仍然是零(沒有改變)，觸發器代碼不知道發生了錯誤，因此它繼續執行。最終結果是，觸發器可能部份失敗。
這裏是一個具體的例子。當ORDERS對於ORDITEMS具有一個限制刪除規則時，CUSTOMER對於ORDERS具有一個級聯刪除規則。當前的CUSTOMER記錄有兩條相關的ORDERS記錄，第一條沒有關聯的ORDITEMS記錄，第二條有一條相關的ORDITEMS記錄。當你刪除CUSTOMER記錄時，你想會發生什麼情況?你會得到一條觸發失敗的錯誤資訊，但你會發現CUSTOMER記錄的第一條ORDERS記錄已被刪除。僅第二條ORDERS記錄還存在，當然，現在它成為一個沒有父記錄的記錄。
(你可能會認為這是一個不可思議的例子，我在實際中確實發生了這樣的問題。)
解決的辦法是，必須在錯誤處理程式中將pnError設置為非零的值;如果你查看SFMaintForm的ErrTriggerFailed方法代碼，你會發現它只做了這一點。然而，那樣做並沒有完全解決這一問題：VFP引用完整性(RI)生成器生成的RIDelete和RIUpdate過程中的一個BUG(刪除和更新一個子記錄)也必須改正(參見下面的關於RIDelete的代碼)。如果pnError非零，這些常式設置llRetVal的值(返回值)為.F.，以告訴其他常式觸發失敗。然而，由於RIOpen常式被調用來在非緩衝方式下打開子表以檢查與父表相關的記錄，下一級的觸發器(如，檢查子表的子表)在未遇到unlock語句時不會被啟動，這出現在llRetVal設置之後。這樣，當試著刪除或更新孫記錄(致使觸發錯誤資訊出現的記錄)時發生的錯誤將不會造成llRetVal被設置為.F.，因此該等級的觸發器不會失敗(即使它確實失敗了)。解決這一問題的辦法是象下面那樣，移動llRetVal語句到unlock命令以後。由於RIDelete和RIUpdate是普通的常式，你可以從資料庫的儲存代碼中複製這些代碼，粘貼它們到資料庫的儲存代碼的結束部份(在RI註腳行後)並在這裏修改。採用這種方法，你不必在每次重新生成RI代碼後，都進行相同的修改。

procedure RIDELETE
local llRetVal
llRetVal=.t.
IF (ISRLOCKED() and !deleted()) OR !RLOCK()
llRetVal=.F.
ELSE
IF !deleted()
DELETE
IF CURSORGETPROP('BUFFERING') > 1
=TABLEUPDATE()
ENDIF

*** 剪切下麵一行...
* llRetVal=pnerror=0
ENDIF not already deleted
ENDIF
UNLOCK RECORD (RECNO())
*** ... 把它粘貼到這裏

llRetVal=pnerror=0
RETURN llRetVal
違反欄位規則
在VFP 5(包括5.0a)中的函數sys(2018)和aerror()中存在一個BUG，當一個欄位規則違反時，實際的欄位名將不可用。相反，你得到兩個字串之一：要麼是欄位的RuleText屬性(如果它是填寫了的)，要麼是一個一般的資訊“欄位驗證規則衝突”。
怎麼會是這樣?那麼，怎樣才能象你希望的那樣：在該欄位沒有RuleText時，顯示一條資訊“請為欄位<欄位標牌>輸入一個合法的值”?問題是如果你不知道那一個欄位的規則被違反，你又如何知道用那一個欄位的標牌呢?假如你想設置焦點到發生錯誤的欄位然後顯示錯誤資訊，更加方便用戶修改出問題的欄位的值?假如你想改變那個控制項的背境顏色，怎樣顯而易見的告訴用戶哪一欄位發生了錯誤呢?
在VFP 5.0(不是5.0a)中，要改正這一問題，我們需要做兩件事中的一件：如果這個串是“欄位驗證規則衝突”，我們將從串中挖出該欄位。如果那不是一個串，我們必須在資料庫中找到給出RuleText屬性的欄位。幸運的是，在VFP 5.0a，一個未編檔函數aerror()，它可以建立一個5個元素的陣列，其中包含了欄位號，利用它我們可以找到我們要找的欄位名。
SFMaintForm.ErrFieldRuleFailed方法處理這種behavior;代碼如下：
local loObject，
lcAlias，
lcTable，
lcMessage，
lcField，
lnSpace1，
lnSpace2，
lnI，
lcText

* If the field rule was checked and failed because
* the user clicked on a button with the Cancel
* property set to .T. or if the button has an lCancel
* property (which is part of the SFCommandButton base
* class) and it's .T.， don't bother doing anything
* else。

loObject = sys(1270)
if lastkey() = 27 or (type('loObject') = 'O' and
type('loObject.lCancel') = 'L' and loObject.lCancel)
return .NULL.
endif lastkey() = 27 ...
with This

* Figure out which field failed。

lcAlias = alias(.aErrorInfo[.nLastError，
cnAERR_WORKAREA])
lcTable = cursorgetprop('SourceName'， lcAlias)
lcMessage = .aErrorInfo[.nLastError， cnAERR_MESSAGE]
lcField = lower(lcAlias + '.' +
field(.aErrorInfo[.nLastError， cnAERR_TRIGGER]， lcAlias))

* Display the error message and find the object whose
* ControlSource is the field。

messagebox(lcMessage， MB_ICONSTOP， _screen.Caption)
loObject = .FindControlSourceObject(lcField)

* Set the lFieldRuleFailed flag to .T.

.lFieldRuleFailed = .T.
endwith
return loObject
ErrFieldRuleFailed要做的第一件事是檢查用戶是否單擊了表單中的“取消”按鈕，並試著設置焦點到該按鈕，以啟動當前控制項的欄位的驗證規則。由於在此情況下，它不必再顯示錯誤資訊，因此ErrFieldRuleFailed除此之外不做任何事情，簡單返回。
如果用戶沒有選擇”取消”，ErrFieldRuleFailed指出那一欄位發生了問題，它調用FindControlSourceObject方法來找出表單中的那一對像是綁定到該欄位。如果找到該物件，它返回一個引用到物件，因此HandleError可以設置焦點到它。
ErrFieldRuleFailed也設置一個叫lFieldRuleFailed的表單屬性為.T.，它可用於當欄位規則失敗時，控制項的Valid方法來避免控制項失去焦點。需要它的原因是因為欄位驗證規則違反程式在控制項的Valid之前被啟動。當錯誤被處理後，Valid方法啟動，正常地返回.T.，允許控制項失去焦點(即使它包含了一個錯誤的值)。以下是避免這一情況的SFTextBox的Valid方法代碼：
if type('Thisform.lFieldRuleFailed') = 'L' and
Thisform.lFieldRuleFailed
Thisform.lFieldRuleFailed = .F.
return 0
endif type('Thisform.lFieldRuleFailed') = 'L' ...
例子
要查看examples是如何在這個錯誤處理機制中處理預料不到的錯誤和處理的細節，運行示例檔中的MYAPP.APP。從檔功能表中選擇“錯誤表單一”並單擊“這將造成一個錯誤”按鈕。該按鈕的Click方法包含了兩個錯誤，因此你在第一個錯誤出現時的對話方塊中選擇繼續時，第二個錯誤將出現並且錯誤對話方塊將再次出現。如果這次你選擇取消，第二個錯誤不會出現，但程式停留在運行狀態且表單仍然是打開的。選擇退出來乾淨地退出程式，恢復功能表條，關閉表單，並重新設置環境到運行前的狀態。重試，當然，造成相同的錯誤資訊出現，由於該問題已經改正。
要查看特殊的錯誤是如何處理的，從檔功能表中選擇Customer表單。從檔功能表中選擇新建，在Customer ID中輸入“ALFKI”，然後從檔功能表中選擇選擇保存。你會得一條錯誤資訊“Customer ID 已經存在”;由於該欄位是該表的主關鍵字並且已經的一個名為ALFKI的記錄存在於該欄位中，一條主關鍵字違反的錯誤將發生並將象展示的那樣被處理。要查看欄位規則失敗的結果，在Company欄位中輸入“Test”;該欄位有一個規則避免輸入該值。當你想離開該欄位時，你會看到欄位規則失敗的錯誤資訊。清空Company欄位。移運游標到City欄位並輸入“Regina”，然後從檔功能表中選擇保存。你會得到一條表規則失敗的錯誤資訊;該表有一個規則拒絕接受City欄位的值為“Regina”(最後，誰想生活在這裏)。從檔功能表中選擇撤銷來移去新增加的記錄。
要查看當”取消”按鈕被按下時，SFMaintForm是如何避免一個欄位規則失敗資訊，在Company欄位上輸入”test”並在離開該欄位前單擊“撤銷”按鈕。
要查看DE問題是怎樣處理的，在文件管理器中將CUSTOMER.DBF改名為CUST.DBF，運行MYAPP並打開Customer表單。注意在你回應所出現的錯誤資訊後，表單關閉了。將CUST.DBF的名字改回到CUSTOMER.DBF。
要查看觸發器失敗問題，退出應用程式，打開TESTDATA資料庫，流覽CUST_ORDERS視圖。該視圖顯示表CUSTOMER，ORDERS，和ORDITEMS中的記錄資訊。注意ALFKI客戶有一些訂貨但第一個(ORDER_ID=10062)沒有訂貨細節(LINE_NO是.NULL.)。運行MYAPP，打開Customer表單，從檔功能表中選擇刪除，當確認視窗出現時選擇確認確認刪除。注意觸發失敗資訊將出現;這是由於在表ORDERS與ORDITEMS間存在限制刪除的規則。然而，注意多次得到這一資訊，並在最後一次反應後，ALFKI客戶被刪除了。退出程式，打開CUSTOMERS，注意ALFKI真的已經被刪除了。現在
USE ORDERS ORDER CUST_ID
並注意很多客戶ALFKI的訂單記錄仍然存在;當然，它們都成了沒有父記錄的孤記錄。
要修復這一問題，按以下步驟：
• CLOSE ALL
• 解壓DATA.ZIP(我們弄亂了資料，因此我們需要恢復它們)。
• OPEN DATABASE TESTDATA
• MODIFY PROCEDURES
• 象前面描述的那樣，將RIDelete過程中的llRetVal移到UNLOCK語句後。保存並關閉代碼視窗。
• MODIFY PROJECT MYAPP
• 打開類庫SFForms中的SFMaintForm類，進入ErrTriggerFailed方法的代碼視窗，到代碼尾部，去掉pnError的注釋。存檔並關閉代碼視窗。
• 重建MYAPP並運行它。
• 打開Customer表單，從檔功能表中選擇刪除，當被詢問確認刪除時選擇確認確認刪除。
此時，你會得到一條單一的觸發器失敗資訊，並且ALFKI客戶任然存在。錯誤被控制了!
要檢查的其他東西：
• 要查看SFErrorMgr是如何登錄錯誤的，打開ERRORLOG表並流覽它。特別注意MEMVARS欄位;它包含了發生錯誤時在調用堆疊上的每一個過程中的每一個變數的值。
• 修改APPLIC.INI文件中的Developer為Yes。該值被過程STARTUP.PRG用於設置oError的lDeveloper屬性。打開資源管理器並按下F5(這是必要的，這樣VFP才知道INI檔被修改了)，然後運行MYAPP。從檔功能表選擇“錯誤表單1”並單擊檔頭按鈕。注意一個調試選項出現在錯誤對話方塊中。這對於調試一個運行中的程式來說是真正有用的。當然，跟蹤視窗顯示SFErrorMgr類的是ErrorHandler方法代碼，由於那是SET STEP ON命令執行的地方。要返回到真正造成錯誤的代碼中，你必須為錯誤處理鏈中的每一常式單擊Debugger的工具條中的跳出按鈕一次。
• 在“錯誤表單1”中的“這將造致一個錯誤但不會發生什麼”按鈕正象它所說的那樣做：單擊它不會發生什麼。如果你查看它的Click方法，看起來會令人驚呀，因為在其中有兩個錯誤。然而，查看Error方法並注意與其他物件不同的地方，它直接調用其父容器的Error方法。這是一個問題：該按鈕是放置在一個PageFrame的頁面中，並且該頁是一個VFP的基類頁，它沒有Error方法代碼，這意味著當一個錯誤出現時什麼也不會發生。就象ON ERROR*一樣，這是一個使你的程式不出現錯誤住處的好方法。不是沒有錯誤，只是不顯示錯誤資訊。這就是為什麼所有SFCTRLS.VCX中的基類要向上級容器類查找直到找到第一個具有Error方法代碼的類。
多樣的錯誤資訊
這裏是一些關於VFP錯誤處理時，你應知道的東西。
• 在VFP 6以前的版本中，VFP自動伺服器不能適當地返回錯誤條件到它的調用程式。它們被附加的comreturnerror()函數修改了。該函數移動COM例外結構用錯誤發生資訊。它接受兩個參數：cExceptionSource，伺服器的名字，和cExceptionText，你想返回的資訊。MYAPP.APP中的form1調用名為MyServer的自動服務程式Test()方法演示了這一點(MyServer專案包含在sample檔中)。
• 如果type()在錯誤處理鏈中的任何地方被使用，你不會總是得到正確的錯誤資訊。理由是type()使用了某些VFP的錯誤處理內核，作為結果，當被type()息檢測的變數或屬性不存在時，message()的內容可能被複寫。這就是為什麼有時你的錯誤處理程式會報告“變數未找到”資訊。在VFP 98中，盡可能地使用vartype();它比type()更快且避免了以上問題。
• 在VFP 5中，當綁定控制項的資料源欄位的驗證規則違反時該控制項的Error方法被調用。這允許你控制顯示什麼樣的錯誤資訊和怎樣顯示它們。在VFP 3中，這些錯誤是不可捕捉;VFP適當地為欄位顯示Rule文本(若Rule文本為空，則顯示一個難看的文字資訊)在一個你不能控制的messagebox()對話方塊中。
• 儘管作為local定義的變數在定義它的過程以外是不可見的，但list memory命令可以看見調用堆疊中全部常式中定義的全部變數。這是一件好事情，因為它允許你在發生錯誤時，取得全部變數的一個資訊並將其登錄到一個檔。SFErrorMgr的LogError方法展示了怎樣做。
• list status命令對錯誤處理的幫助並不是很大：它只能看見當前資料會話區中的東西(例如打開的表和SET命令的設置)，因此，如果錯誤處理程式是在默認資料工作期，它不能發現私有資料工作期中的表單發生的錯誤。如果這對你很重要，你可以在使用該命令前轉換到表單的資料工作期或你可以派生SFErrorMgr的一個子類進入表單的oError屬性，這樣作為表單就都在相同的資料工作期了。
• 出於性能方面的原因，當錯誤發生時，你可能不想一次一步地調用父類的代碼，因此你可以直接從一個物件轉跳到表單級的Error方法或SFErrorMgr.ErrorHandler。我的意見是，發生錯誤時，性能不是考慮因素，因此我在本文中保持了類設計清晰和條理。
• error命令是有趣的：它致使用一個錯誤被觸發。如果你想像VFP一樣處理某些類型的“軟”錯誤時，使用它是很方便的。例如，如果file()返回了.F.指出檔不存在，你可以使用error命令強制錯誤處理器啟動這樣你可以得到一般錯誤服務(登錄，顯示，等)。我趨向於儘量少用這種方法;畢竟，當你正在處理一個硬錯誤時，還會受到軟錯誤檢查的干擾。同時，這還取決於你在那裏使用error命令，你可能不會獲得正確的方法名稱和行號資訊，因為它們將反映error命令是在那裏被使用而不是你在那裏發現的問題。
• 當物件方法調用的程式發生錯誤時，物件的Error方法先於on error啟動。這意味著可以在編程中用兩種不同的機制來處理一個錯誤，這要看程式是被如何調用的。這樣，在編碼中的錯誤處理不象在物件中那麼簡單。這是把它們從PRG庫中移到物件庫中的另一個理由。
• 以上觀點還有另一個有趣的方面：如果你的read events語句在一個全局物件的方法中(例如一個application物件)，該物件的Error方法的效果就相當於一個全局錯誤處理器，因為該物件總是在調用堆疊上。你可以用on error結束這種情況，這樣它將只處理不從物件中調用的，PRG代碼中的錯誤。
• 你不能正常地捕捉以下情況：當用戶在TextBox中輸入一個無效的日期值時;VFP顯示“Invalid Date”並不會啟動該控制項的Valid方法。你可以用set notify off命令關閉“Invalid Date”資訊，但是你如果想啟動控制項的Valid方法(例如，要給出一條不同的資訊或帶出日曆控制項)，你必須設置控制項的StrictDateEntry屬性為0。這裏要注意的是：如果用戶輸入了不可用的日期，它將會被置為空格，因此如果你想重新顯示填入的值，你必須在控制項的GotFocus方法中保存它並在Valid中恢復它。
• on error不捕捉報表中的和功能表命令的skip for子句中的錯誤;這些錯誤是不可捕捉的，因此確信你的報表和功能表中的skip for子句中的條件運算式是經過徹底測試的。要確認這一點，編輯APPLIC.INI並設置NoSuchVariable入口為No。打開Windows Explorer並按下F5(這是必要的，這樣VFP會發現INI檔已經被修改)，然後運行MYAPP。在功能表上單擊，並注意VFP錯誤的出現。
結論
在本文中，探討了兩種最佳錯誤處理方案(局部處理大多數錯誤及剩下的由全局處理)。此方案已成功地運用于一系列的應用程式中，儘管我們仍在不斷地完善它。我希望你能找到對你有用的地方。如果你對它有任何改進或有任何改進建議，請通知我。