vba On Error Resume Next 似乎不起作用
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/15459332/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
On Error Resume Next seemingly not working
提问by whytheq
I have the following two lines of code:
我有以下两行代码：
On Error Resume Next
myWorkbook.Sheets("x").Columns("D:T").AutoFit
I've stepped into the macro and executed the line On Error Resume Nextand then on the next line myWorkbook...it does the following:
我已经进入宏并执行了该行On Error Resume Next，然后在下一行myWorkbook...执行以下操作：
Why doesn't the compiler resumethe next line of code?
为什么编译器不恢复下一行代码？
On Errorhas been liberally used throughout the procedures code; I realize best practice is to use this as little as possible but it seems to fit the purpose of this macro.
On Error已在整个程序代码中大量使用；我意识到最好的做法是尽可能少地使用它，但它似乎符合这个宏的目的。
Reading this SO QUESTIONit says that you can't have one set of error trapping within another. How can I guarantee that one set of error trapping has been "closed off" before the code moves on - does On Error Goto 0reset the error trapping? If it does reset then why doesn't resume work in the following?:
阅读这个SO QUESTION它说你不能在另一组中捕获一组错误。我如何保证在代码继续之前一组错误捕获已“关闭” - 是否On Error Goto 0重置错误捕获？如果它确实重置，那么为什么不恢复以下工作？：
Sub GetAction()
Dim WB As Workbook
Set WB = ThisWorkbook
On Error GoTo endbit:
'raise an error
Err.Raise 69
Exit Sub
endbit:
On Error GoTo 0
On Error Resume Next
WB.Sheets("x").Columns("D:T").AutoFit
End Sub
采纳答案by brettdj
An example of an error when the initial error is not closed out.
未关闭初始错误时的错误示例。
Sub GetAction()
Dim WB As Workbook
Set WB = ThisWorkbook
On Error GoTo endbit:
'raise an error
Err.Raise 69
Exit Sub
endbit:
On Error Resume Next
WB.Sheets("x").Columns("D:T").AutoFit
End Sub
回答by Iridium
There is also a VBA setting that will cause On Error ...statements to be ignored and that dialog box to always appear. See this answer for more details on checking/changing the option: https://stackoverflow.com/a/3440789/381588
还有一个 VBA 设置会导致On Error ...语句被忽略并且该对话框总是出现。有关检查/更改选项的更多详细信息，请参阅此答案：https: //stackoverflow.com/a/3440789/381588
回答by grahamj42
As you have found, within the same function or subroutine, On Error Resume Nextdoesn't override On Error Goto ...if it's still active.
如您所见，在同一函数或子例程中，如果它仍然处于活动状态，On Error Resume Next则不会覆盖On Error Goto ...。
You are correct that On Error Goto 0restores the default error handler.
On Error Goto 0恢复默认错误处理程序是正确的。
There are some cases where On Erroris the most appropriate way to handle an exceptional condition. I prefer to use the following structure:
在某些情况下，On Error是处理异常情况的最合适的方法。我更喜欢使用以下结构：
On Error Resume Next
statement which might fail
On Error Goto 0
if statement has failed then ...
This keeps everything together, but in other cases a generic error handler at the end of the procedure can be better.
这将所有内容保持在一起，但在其他情况下，过程结束时的通用错误处理程序可能会更好。
回答by Espen Rosenquist
I've found that in functions/subs that iterates over nested objects, errorhandling might be a drag in VBA. A solution that works for me to better handle complex iterations is separating setting of objects in their own functions, e.g.
我发现在迭代嵌套对象的函数/子程序中，错误处理可能会拖累 VBA。一个对我来说更好地处理复杂迭代的解决方案是在它们自己的函数中分离对象的设置，例如
main function/sub: set FSOfolder = SetFSOFolder(FSOobject, strFolder)
主函数/子函数：set FSOfolder = SetFSOFolder(FSOobject, strFolder)
Private Function SetFSOFolder(FSO as scripting.FileSystemObject, strFolder as string) as Scripting.Folder
on error resume Next
set SetFSOFolder = FSO.GetFolder(strFolder)
on error goto 0
End Function
and then in the next line in main function:
然后在主函数的下一行：
if (not fsofolder is nothing) then
回答by Thom
I agree using On Error Resume Next is not best practice but most/many of my Access apps are not overly sensitive to minor nuances in data integrity (i.e. analytical or reporting, not transactions and not audited). For this reason I use OERN quite often because VBA is very sensitive to some situations that you cannot anticipate entirely. 1 - will the error cause data corruption. If yes handle it. Many routines I use are just crunching a large volume of records and there may be errors in imported data that haven't been fixed. Usually I have a lot of conversion processes that will let the system clean up its own data eventually.
我同意使用 On Error Resume Next 不是最佳实践，但我的大多数/许多 Access 应用程序对数据完整性的细微差别并不太敏感（即分析或报告，而不是交易和未审计）。出于这个原因，我经常使用 OERN，因为 VBA 对某些您无法完全预料的情况非常敏感。1 - 错误是否会导致数据损坏。如果是处理它。我使用的许多例程只是处理大量记录，导入的数据中可能存在尚未修复的错误。通常我有很多转换过程，最终会让系统清理自己的数据。
2 - is the error frequent and non-critical (ie not a key). If yes it's OERN otherwise the error may not be predicable and you end up crashing out or have to write a bunch of I-T-E or Select Case logic to trap it.
2 - 错误频繁且非关键（即不是关键）。如果是，它是 OERN，否则错误可能无法预测，最终会崩溃或必须编写一堆 ITE 或 Select Case 逻辑来捕获它。
回答by user1644564
Don't use On Error Resume Nextinstead write code that shouldn't crash.
不要On Error Resume Next改写不应崩溃的代码。
Note: I am being careful how I phrase that because you never guaranty code doesn't crash. But if you use On Error Resume Nextthen part of the natural flow of your code is for it to crash, which is wrong, big time wrong.
注意：我很小心我的措辞，因为你从不保证代码不会崩溃。但是如果你使用On Error Resume Nextthen 代码自然流的一部分是它崩溃，这是错误的，大错特错。
