(sorry for the likely repost, but it is still not showing on my news serverand after that much typing, I don''t want to lose it)I am considering general error handling routines and have written a samplefunction to look up an ID in a table. The function returns True if it canfind the ID and create a recordset based on that ID, otherwise it returnsfalse.**I am not looking for comments on the usefulness of this function - it isonly to demonstrate error handling**There are three versions of this code. David Fenton says under the earlierthread "DAO peculiarity in A97?" that version 1 is bad since it has multiplelines covered by On Error Resume Next and that a danger exists of this''spilling over'' into another block of code. Can anyone demonstrate this?Do others have experience of this happening?It seems he would prefer version 2. But I am wondering - if I cannot relyon the error handling to be reset when I exit my function, can I guaranteethere is zero possibility of an error in the Exit_Handler part in version 2?(e.g. the recordset wasn''t nothing, but trying to close it causes an error).If there is an error in the Exit_Handler part, we obviously get stuck in anever-ending loop, so to some extent it would make sense to make sure thatthis cannot happen. The code is also less verbose, particularly when thereare many objects to be cleared up. Perhaps the answer is version 3 whichtacks on a final ''On Error GoTo 0'' but I have never seen anyone write afunction with that type of error handling.**I am undecided and seeking the group''s opinions**Public Function ContactExists1(lngConID As Long) As BooleanOn Error GoTo Err_HandlerDim dbs As DAO.DatabaseDim rst As DAO.RecordsetDim strSQL As StringstrSQL = "SELECT tblContact.* FROM tblContact WHERE " & _"ConID=" & CStr(lngConID)Set dbs = CurrentDbSet rst = dbs.OpenRecordset(strSQL, dbOpenForwardOnly, dbReadOnly)If Not rst.EOF ThenContactExists1 = TrueEnd IfExit_Handler:On Error Resume Nextrst.CloseSet rst = NothingSet dbs = NothingExit FunctionErr_Handler:MsgBox Err.Description, vbExclamation, "Error No: " & Err.NumberResume Exit_HandlerEnd FunctionPublic Function ContactExists2(lngConID As Long) As BooleanOn Error GoTo Err_HandlerDim dbs As DAO.DatabaseDim rst As DAO.RecordsetDim strSQL As StringstrSQL = "SELECT tblContact.* FROM tblContact WHERE " & _"ConID=" & CStr(lngConID)Set dbs = CurrentDbSet rst = dbs.OpenRecordset(strSQL, dbOpenForwardOnly, dbReadOnly)If Not rst.EOF ThenContactExists2 = TrueEnd IfExit_Handler:If Not rst Is Nothing Thenrst.CloseSet rst = NothingEnd IfIf Not dbs Is Nothing ThenSet dbs = NothingEnd IfExit FunctionErr_Handler:MsgBox Err.Description, vbExclamation, "Error No: " & Err.NumberResume Exit_HandlerEnd FunctionPublic Function ContactExists3(lngConID As Long) As BooleanOn Error GoTo Err_HandlerDim dbs As DAO.DatabaseDim rst As DAO.RecordsetDim strSQL As StringstrSQL = "SELECT tblContact.* FROM tblContact WHERE " & _"ConID=" & CStr(lngConID)Set dbs = CurrentDbSet rst = dbs.OpenRecordset(strSQL, dbOpenForwardOnly, dbReadOnly)If Not rst.EOF ThenContactExists3 = TrueEnd IfExit_Handler:On Error Resume Nextrst.CloseSet rst = NothingSet dbs = NothingOn Error GoTo 0Exit FunctionErr_Handler:MsgBox Err.Description, vbExclamation, "Error No: " & Err.NumberResume Exit_HandlerEnd Function 解决方案 "Anthony England" <ae******@oops.co.uk> wrote innews:dp**********@nwrdmz01.dmz.ncs.ea.ibs-infra.bt.com: (sorry for the likely repost, but it is still not showing on my news server and after that much typing, I don''t want to lose it) I am considering general error handling routines and have written a sample function to look up an ID in a table. The function returns True if it can find the ID and create a recordset based on that ID, otherwise it returns false. **I am not looking for comments on the usefulness of this function - it is only to demonstrate error handling** There are three versions of this code. David Fenton says under the earlier thread "DAO peculiarity in A97?" that version 1 is bad since it has multiple lines covered by On Error Resume Next and that a danger exists of this ''spilling over'' into another block of code. Can anyone demonstrate this?Even *I* can''t demonstrate it.However, I had an app that had problems that could only be explainedby the use of On Error Resume Next. When those were removed (orallowed to apply to only one line at a time), the problems with dataerrors being lost disappeared. This was several years ago.Now, philosophically, I have a definite problem with relying on it.It''s lazy programming, in my opinion.Using it shows that you *know* an error is going to happen. To me,that shows that, instead of saying "ignore the error" you shouldtrap for it and respond accordingly.The main reason for this is that you can''t anticipate every possibleerror, and there could be errors that you *don''t* want to ignore(which is what was happening in the app I cited above).This is, of course, separate from the issue of scope, which I can''treally prove. All I know is that it appeared to me that On ErrorResume Next was not going out of scope when subroutines ended. Do others have experience of this happening? It seems he would prefer version 2. But I am wondering - if I cannot rely on the error handling to be reset when I exit my function, can I guarantee there is zero possibility of an error in the Exit_Handler part in version 2? (e.g. the recordset wasn''t nothing, but trying to close it causes an error). If there is an error in the Exit_Handler part, we obviously get stuck in a never-ending loop, so to some extent it would make sense to make sure that this cannot happen. The code is also less verbose, particularly when there are many objects to be cleared up. Perhaps the answer is version 3 which tacks on a final ''On Error GoTo 0'' but I have never seen anyone write a function with that type of error handling.I don''t know what errors could happen in closing a recordset. If youare avoiding doing it my way because of a worry about an unforeseenerror, then it seems to me to be contradictory of your seemingpreference for a method that ignores *all* errors, anticipated ornot. In other words, you seem to prefer a method that ignores *all*unforeseen errors to a method that may break if *one* unforeseenerror occurs.That seems extremely unwise to me.--David W. Fenton http://www.dfenton.com/usenet at dfenton dot com http://www.dfenton.com/DFA/"David W. Fenton" <XX*******@dfenton.com.invalid> wrote in messagenews:Xn**********************************@127.0.0. 1... "Anthony England" <ae******@oops.co.uk> wrote in news:dp**********@nwrdmz01.dmz.ncs.ea.ibs-infra.bt.com: However, I had an app that had problems that could only be explained by the use of On Error Resume Next. When those were removed (or allowed to apply to only one line at a time), the problems with data errors being lost disappeared. This was several years ago. Now, philosophically, I have a definite problem with relying on it. It''s lazy programming, in my opinion. Do others have experience of this happening? It seems he would prefer version 2. But I am wondering - if I cannot rely on the error handling to be reset when I exit my function, can I guarantee there is zero possibility of an error in the Exit_Handler part in version 2? (e.g. the recordset wasn''t nothing, but trying to close it causes an error). If there is an error in the Exit_Handler part, we obviously get stuck in a never-ending loop, so to some extent it would make sense to make sure that this cannot happen. The code is also less verbose, particularly when there are many objects to be cleared up. Perhaps the answer is version 3 which tacks on a final ''On Error GoTo 0'' but I have never seen anyone write a function with that type of error handling. I don''t know what errors could happen in closing a recordset. If you are avoiding doing it my way because of a worry about an unforeseen error, then it seems to me to be contradictory of your seeming preference for a method that ignores *all* errors, anticipated or not. In other words, you seem to prefer a method that ignores *all* unforeseen errors to a method that may break if *one* unforeseen error occurs. That seems extremely unwise to me. -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/I had a problem similar to the one David describes with On Error ResumeNext. It was particularly bad because I let it get out to a customer thatway (shame on me). It caused some highly intermittent problems that wereextremely difficult to pin down. It was several years ago and I no longerhave the code.I also agree that its use is "lazy programming" but I still use it onoccasion. Properly trapping errors is always better, but I''m a lazyprogrammer. The solution that I''ve come up with is to never, ever leave asection of code with On Error Resume Next "unterminated". I consider OnError Goto 0 (or Goto something else) a proper termination. I used to putErr.Clear ahead of the Goto, but that didn''t seem to make any difference.Also, keep blocks of code with Resume Next as small as possible and be verycertain that code that doesn''t get run and doesn''t generate an error can''tcause problems elsewhere. This "solution" has worked well for me.--Randy Harristech at promail dot comI''m pretty sure I know everything that I can remember.Another perspective: I sometimes trap for particular errors that I wantto do special processing with, then use Resume Next after thatprocessing so the user never sees any error I don''t want them to. AsDavid said, some errors shouldn''t be ignored, but at the same time I''drather keep frivolous errors from popping up than show every error.Note that it would be difficult to trap EVERY possible error that isnot terribly important, or rather it would take a lot of code. 这篇关于David Fenton是否正确处理错误？ （重职？）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！ 上岸，阿里云！
