我有以下两行代码:
On Error Resume Next
myWorkbook.Sheets("x").Columns("D:T").AutoFit
我已进入宏并执行了行On Error Resume Next
,然后在下一行myWorkbook...
执行以下操作:
为什么编译器不能恢复下一行代码?
On Error
在程序代码中被广泛使用;我意识到最好的做法是尽可能少地使用它,但它似乎符合这个宏的目的。
读这个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
答案 0 :(得分:9)
还有一个VBA设置会导致On Error ...
语句被忽略,并且该对话框始终显示。有关检查/更改选项的更多详细信息,请参阅此答案:https://stackoverflow.com/a/3440789/381588
答案 1 :(得分:3)
初始错误未关闭时的错误示例。
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
答案 2 :(得分:1)
正如您所发现的那样,On Error Resume Next
在同一个函数或子例程中,如果它仍处于活动状态,则不会覆盖On Error Goto ...
。
你是正确的On Error Goto 0
恢复默认错误处理程序。
在某些情况下, On Error 是处理异常情况的最合适方式。我更喜欢使用以下结构:
On Error Resume Next
statement which might fail
On Error Goto 0
if statement has failed then ...
这可以将所有内容保持在一起,但在其他情况下,过程结束时的通用错误处理程序可能会更好。
答案 3 :(得分:1)
我发现在函数/ subs中迭代嵌套对象时,错误处理可能是VBA中的拖拽。对我来说更好地处理复杂迭代的解决方案是在自己的函数中分离对象的设置,例如
主要功能/子: 设置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
然后在main函数的下一行:
if (not fsofolder is nothing) then
答案 4 :(得分:1)
我同意使用On Error Resume Next不是最佳做法,但我的大部分/许多Access应用程序对数据完整性的细微差别(即分析或报告,而非交易和未审计)不过分敏感。出于这个原因,我经常使用OERN,因为VBA对某些你无法完全预料到的情况非常敏感。 1 - 错误会导致数据损坏。如果是,请处理它。我使用的许多例程只是处理大量记录,导入的数据中可能存在未修复的错误。通常我会有很多转换过程让系统最终清理自己的数据。
2 - 错误是频繁且非关键的(即不是关键)。如果是,那就是OERN,否则错误可能是不可预测的,你最终会崩溃或者必须编写一堆I-T-E或Select Case逻辑来捕获它。
答案 5 :(得分:-3)
请勿使用On Error Resume Next
代写不应崩溃的代码。
注意:我很谨慎,因为你从不保证代码不会崩溃。但是如果你使用On Error Resume Next
,那么代码的部分自然流程就会崩溃,这是错误的,大错的时候。