David Fenton是否正确处理错误？ （重职？） [英] Is David Fenton right about error handling? (re-post?)
问题描述
（对不起可能的转发，但它仍然没有在我的新闻服务器上显示
，在那么多打字之后，我不想失去它）
我正在考虑一般错误处理例程，并编写了一个示例
函数来查找表中的ID。该函数返回True，如果它可以找到ID并根据该ID创建记录集，否则返回
false。
**我不是在寻找关于这个功能的用处的评论 - 它只是为了证明错误处理而是
**
有三个版本这段代码。大卫芬顿说，在早先的
线程中，A97中的DAO特性？版本1是坏的，因为它有On Error Resume Next所涵盖的多个
行，并且存在这样的危险：
''溢出'到另一个代码块。任何人都可以证明这一点吗？
其他人是否有过这种情况的经历？
看来他更喜欢第2版。但我想知道 - 如果我不能依赖
我退出函数时要重置的错误处理
，我可以保证
版本2中Exit_Handler部分出现错误的可能性为零吗？
（例如记录集不是什么，但试图关闭它会导致错误）。
如果Exit_Handler部分出现错误，我们显然会陷入
永无止境的循环，所以在某种程度上确保
这是不可能的。代码也不那么冗长，特别是当有很多对象需要清理时。也许答案是版本3
在最后的'On Error GoTo 0'上进行修复但我从未见过有人用这种类型的错误处理写了一个
函数。
**我尚未决定并寻求小组的意见**
公共函数ContactExists1（lngConID As Long）As Boolean
错误GoTo Err_Handler
Dim dbs作为DAO.Database
Dim rst作为DAO.Recordset
Dim strSQL As String
strSQL =" SELECT tblContact。* FROM tblContact WHERE" &安培; _
" ConID =" &安培; CStr（lngConID）
设置dbs = CurrentDb
设置rst = dbs.OpenRecordset（strSQL，dbOpenForwardOnly，dbReadOnly）
如果不是rst.EOF则
ContactExists1 = True
结束如果
Exit_Handler：
On Error Resume Next
rst.Close
Set rst = Nothing
Set dbs = Nothing
退出函数
Err_Handler：
MsgBox Err.Description，vbExclamation，"错误号：" &安培; Err.Number
恢复Exit_Handler
结束函数
公共函数ContactExists2（lngConID As Long）As Boolean
错误GoTo Err_Handler
Dim dbs作为DAO.Database
Dim rst作为DAO.Recordset
Dim strSQL As String
strSQL =" SELECT tblContact。* FROM tblContact WHERE" &安培; _
" ConID =" &安培; CStr（lngConID）
设置dbs = CurrentDb
设置rst = dbs.OpenRecordset（strSQL，dbOpenForwardOnly，dbReadOnly）
如果不是rst.EOF则
ContactExists2 = True
结束如果
Exit_Handler：
如果不是第一个没有那么
rst.Close
设置rst =无什么
结束如果
如果不是dbs什么都没有那么
设置dbs =没什么
结束如果
退出函数
Err_Handler：
MsgBox Err.Description，vbExclamation，"错误号：" &安培; Err.Number
恢复Exit_Handler
结束函数
公共函数ContactExists3（lngConID As Long）As Boolean
错误GoTo Err_Handler
Dim dbs作为DAO.Database
Dim rst作为DAO.Recordset
Dim strSQL As String
strSQL =" SELECT tblContact。* FROM tblContact WHERE" &安培; _
" ConID =" &安培; CStr（lngConID）
设置dbs = CurrentDb
设置rst = dbs.OpenRecordset（strSQL，dbOpenForwardOnly，dbReadOnly）
如果不是rst.EOF则
ContactExists3 = True
结束如果
Exit_Handler：
On Error Resume Next
rst.Close
Set rst = Nothing
Set dbs = Nothing
On Error GoTo 0
退出函数
Err_Handler：
MsgBox Err.Description，vbExclamation，"错误号： &安培; Err.Number
恢复Exit_Handler
结束功能
< blockquote>安东尼英格兰 < AE ****** @ oops.co.uk>写道：
news：dp ********** @ nwrdmz01.dmz.ncs.ea.ibs-infra.bt.com:
（对不起可能的转发，但它仍然没有显示在我的
新闻服务器上，经过那么多打字，我不想失去它）
我在考虑一般错误处理例程并编写了一个示例函数来查找表中的ID。如果函数
能够找到ID并根据该ID创建记录集，则返回True，否则返回false。
**我不是在寻找评论这个功能的用处
- 它只是为了演示错误处理**
这段代码有三个版本。大卫芬顿在早期的话题中说道：A97中的DAO特性？那个版本1很糟糕，因为它有多行由On Error Resume Next和
覆盖这个溢出到另一个代码块的危险。谁能证明这一点？
即使*我*也无法证明。
但是，我有一个应用程序有问题，只能解释<通过使用On Error Resume Next获得
。当这些被删除时（或者每次只允许
申请一行），数据丢失的问题就会消失。这是几年前的事了。
现在，从理论上讲，我依赖它确实存在问题。
在我看来这是懒惰的编程。
使用它表明你*知道*将会发生错误。对我来说，
表明，而不是说忽略错误。你应该为它获得
陷阱并作出相应的回应。
主要原因是你无法预料到每一个可能的
错误，可能有错误你不想忽略
（这就是我上面引用的app中发生的事情）。
当然，这与范围问题是分开的，我无法确认这个问题。我所知道的是，在我看来，On Error
Resume Next在子程序结束时没有超出范围。
其他人是否有过这方面的经验？功能时，如果我不能依赖错误处理重置，我可以保证没有错误的可能性在版本2中的Exit_Handler部分？ （例如记录集不是什么，但试图关闭它会导致错误）。如果Exit_Handler部分出现
错误，我们显然会陷入一个永无止境的循环，所以在某种程度上，确保这不会发生是有意义的。代码也不那么冗长，特别是当有很多对象需要清理时。
也许答案是版本3，它决定了最后的''On Error
GoTo 0''但是我从来没有见过有人用这种类型的错误处理来编写函数。
我不知道在关闭记录集时会发生什么错误。如果你因为担心无法预料的
错误而无法按照我的方式行事，那么在我看来，你似乎与你的看似相矛盾
首选项忽略* all *错误，预期或
不是。换句话说，你似乎更喜欢一种忽略* all *
意外错误的方法，如果发生* one * unforeseen
错误，该方法可能会中断。
这对我来说似乎非常不明智。
-
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
< br>
" David W. Fenton" < XX ******* @ dfenton.com.invalid>在消息中写道
news：Xn ********************************** @ 127.0 0.0。 1 ..." Anthony England" < AE ****** @ oops.co.uk>在
新闻中写道：dp ********** @ nwrdmz01.dmz.ncs.ea.ibs-infra.bt.com:
但是，我有一个应用程序那些问题只能通过使用On Error Resume Next来解释。当这些被删除（或允许一次仅应用于一行）时，数据错误丢失的问题就消失了。这是几年前的事了。
现在，从哲学的角度来看，我依赖它确实存在问题。
在我看来，它是懒惰的编程。
其他人是否有过这种情况的经历？
看来他更喜欢第2版。但我想知道 - 如果我不能依靠错误处理来重置我退出了我的
功能，我可以保证在版本2中的Exit_Handler部分出现错误的可能性为零吗？ （例如记录集不是什么，但试图关闭它会导致错误）。如果Exit_Handler部分出现
错误，我们显然会陷入一个永无止境的循环，所以在某种程度上，确保这不会发生是有意义的。代码也不那么冗长，特别是当有很多对象需要清理时。
也许答案是版本3，它决定了最后的''On Error
GoTo 0''但是我从来没有见过有人用这种类型的错误处理来编写函数。
我不知道在关闭记录集时会发生什么错误。如果你因为担心无法预料的错误而无法按照自己的方式行事，那么在我看来，你似乎忽略了一种忽略* all *错误的方法的偏好，预期或
不。换句话说，您似乎更喜欢忽略* all *
无法预料的错误的方法，如果发生* one * unforeseen
错误，可能会破坏。
这似乎非常对我不明智。
-
David W. Fenton http ：//www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
我遇到的问题类似于David描述的On Error Resume
下一步。这特别糟糕，因为我让它以一种方式向客户说出（对我来说是耻辱）。它造成了一些非常难以确定的非常间歇性的问题。这是几年前的事了，我不再需要b $ b了代码。
我也同意它的使用是懒惰编程。但我仍然在
场合使用它。正确地捕获错误总是更好，但我是一个懒惰的b $ b程序员。我提出的解决方案是永远不会留下一个带有On Error Resume Next" unterminated"的代码段。
。我认为On
错误转到0（或转到别的东西）正确的终止。我以前在Goto之前放了
Err.Clear，但这似乎没有任何区别。
另外，请使用Resume Next保留代码块尽可能小，并且非常确定那些没有运行并且不会产生错误的代码不能在其他地方引起问题。这种解决方案对我来说效果很好。
-
兰迪哈里斯
tech at promail dot com
我很确定我知道我能记住的一切。
另一个观点：我有时会陷入我想要的特定错误
要进行特殊处理，然后使用Resume Next
处理，这样用户就不会看到任何我不想要的错误。正如大卫所说，有些错误不应该被忽略，但与此同时我会把b / b
更多地保持轻浮错误而不是显示每一个错误。
请注意，很难捕获每个可能的错误，而不是非常重要，或者说需要大量的代码。
(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?
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 am undecided and seeking the group''s opinions**
Public Function ContactExists1(lngConID As Long) As Boolean
On Error GoTo Err_Handler
Dim dbs As DAO.Database
Dim rst As DAO.Recordset
Dim strSQL As String
strSQL = "SELECT tblContact.* FROM tblContact WHERE " & _
"ConID=" & CStr(lngConID)
Set dbs = CurrentDb
Set rst = dbs.OpenRecordset(strSQL, dbOpenForwardOnly, dbReadOnly)
If Not rst.EOF Then
ContactExists1 = True
End If
Exit_Handler:
On Error Resume Next
rst.Close
Set rst = Nothing
Set dbs = Nothing
Exit Function
Err_Handler:
MsgBox Err.Description, vbExclamation, "Error No: " & Err.Number
Resume Exit_Handler
End Function
Public Function ContactExists2(lngConID As Long) As Boolean
On Error GoTo Err_Handler
Dim dbs As DAO.Database
Dim rst As DAO.Recordset
Dim strSQL As String
strSQL = "SELECT tblContact.* FROM tblContact WHERE " & _
"ConID=" & CStr(lngConID)
Set dbs = CurrentDb
Set rst = dbs.OpenRecordset(strSQL, dbOpenForwardOnly, dbReadOnly)
If Not rst.EOF Then
ContactExists2 = True
End If
Exit_Handler:
If Not rst Is Nothing Then
rst.Close
Set rst = Nothing
End If
If Not dbs Is Nothing Then
Set dbs = Nothing
End If
Exit Function
Err_Handler:
MsgBox Err.Description, vbExclamation, "Error No: " & Err.Number
Resume Exit_Handler
End Function
Public Function ContactExists3(lngConID As Long) As Boolean
On Error GoTo Err_Handler
Dim dbs As DAO.Database
Dim rst As DAO.Recordset
Dim strSQL As String
strSQL = "SELECT tblContact.* FROM tblContact WHERE " & _
"ConID=" & CStr(lngConID)
Set dbs = CurrentDb
Set rst = dbs.OpenRecordset(strSQL, dbOpenForwardOnly, dbReadOnly)
If Not rst.EOF Then
ContactExists3 = True
End If
Exit_Handler:
On Error Resume Next
rst.Close
Set rst = Nothing
Set dbs = Nothing
On Error GoTo 0
Exit Function
Err_Handler:
MsgBox Err.Description, vbExclamation, "Error No: " & Err.Number
Resume Exit_Handler
End Function
"Anthony England" <ae******@oops.co.uk> wrote in
news: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 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.
Using it shows that you *know* an error is going to happen. To me,
that shows that, instead of saying "ignore the error" you should
trap for it and respond accordingly.
The main reason for this is that you can''t anticipate every possible
error, 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''t
really prove. All I know is that it appeared to me that On Error
Resume 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 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/
"David W. Fenton" <XX*******@dfenton.com.invalid> wrote in message
news: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 Resume
Next. It was particularly bad because I let it get out to a customer that
way (shame on me). It caused some highly intermittent problems that were
extremely difficult to pin down. It was several years ago and I no longer
have the code.
I also agree that its use is "lazy programming" but I still use it on
occasion. Properly trapping errors is always better, but I''m a lazy
programmer. The solution that I''ve come up with is to never, ever leave a
section of code with On Error Resume Next "unterminated". I consider On
Error Goto 0 (or Goto something else) a proper termination. I used to put
Err.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 very
certain that code that doesn''t get run and doesn''t generate an error can''t
cause problems elsewhere. This "solution" has worked well for me.
--
Randy Harris
tech at promail dot com
I''m pretty sure I know everything that I can remember.
Another perspective: I sometimes trap for particular errors that I want
to do special processing with, then use Resume Next after that
processing so the user never sees any error I don''t want them to. As
David said, some errors shouldn''t be ignored, but at the same time I''d
rather keep frivolous errors from popping up than show every error.
Note that it would be difficult to trap EVERY possible error that is
not terribly important, or rather it would take a lot of code.
这篇关于David Fenton是否正确处理错误？ （重职？）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
