2013-03-17 23 views
3

我有下面的代码两行:上的错误继续下一步看似不工作

On Error Resume Next 
myWorkbook.Sheets("x").Columns("D:T").AutoFit 

我踏进宏观和执行的行On Error Resume Next再下一行myWorkbook...它执行以下操作:

enter image description here

为什么不能编译简历的下一行代码?

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

我们可以看到完整的代码吗? – brettdj 2013-03-17 09:52:17

+0

@brettdj全部500行! – whytheq 2013-03-17 10:29:34

+0

@brettdj你认为我需要确保前面的代码中的所有其他错误陷阱被关闭吗? – whytheq 2013-03-17 10:30:16

回答

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 
+0

+1谢谢brett – whytheq 2013-03-17 11:07:22

+0

如果我在'endbit:'行后面添加'On Error GoTo 0',那么简历仍然不起作用!这是否意味着@ grahamj42答案是错误的? – whytheq 2013-03-17 15:01:47

1

正如你已经发现,相同功能或子程序中,On Error Resume Next不会覆盖On Error Goto ...如果它仍然活跃。

您正确地认为On Error Goto 0恢复了默认错误处理程序。

在某些情况下,出现错误是处理异常情况的最合适方法。我喜欢用以下结构:

On Error Resume Next 

statement which might fail 

On Error Goto 0 

if statement has failed then ... 

这使一切融合在一起,但在其他情况下,在手术结束一般性错误处理程序会更好。

+0

+1谢谢 - 差不多值得使用'On Error Resume Next' /'On Error Goto 0'就像代码中的括号一样;安全。 – whytheq 2013-03-17 11:06:39

7

还有一个VBA设置会导致On Error ...语句被忽略,并始终显示该对话框。请参阅此答案以获取有关检查/更改选项的更多详细信息:https://stackoverflow.com/a/3440789/381588

+0

?正如你从屏幕上看到的那样,错误不会被忽略。但是'在错误恢复下一个'似乎被忽略。 – whytheq 2013-03-17 11:05:05

+0

@whytheq当错误捕获设置为“在所有错误破” - 错误对话框将显示为*所有*的错误,即使有活动的错误处理程序,这似乎是您所遇到什么。 – Iridium 2013-03-17 12:04:00

+2

感谢值得铭记 - 但它不是该设置 - 其对'打破所有未处理Errors' – whytheq 2013-03-17 12:29:19

-1

请勿使用On Error Resume Next代替编写不应该崩溃的代码。

注:我小心如何我说,因为你从来没有担保的代码不会崩溃。但是如果你使用On Error Resume Next那么你的代码的一部分自然流就是它的崩溃,这是错误的,大错特错。

+0

VBA不是设计来处理所有的“风险”的局面没有'上的错误恢复Next'。怎么样'Application.Inputbox'取消按钮...所以,一厢情愿的想法。但是,毕竟我同意你:) – 2013-03-20 18:35:14

+0

'Try-Catch-Finally'在'VBA'中不会有太多要求! – whytheq 2013-03-21 08:32:41

+4

+1 @ user1644564同意你的答案,但'上的错误恢复Next'已经是有原因的创建 - 如果它永远不要向外界再使用,那么为什么它列入'VBA'规范呢? – whytheq 2013-03-21 08:34:22

1

我发现在迭代嵌套对象的函数/子集中,错误处理可能是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 

,然后在主函数的下一行:

if (not fsofolder is nothing) then 
1

我同意使用上的错误继续下一步并不是最佳实践,但大部分/许多Access应用程序对数据完整性(即分析或报告,而不是交易和未审计)中的细微差别不太敏感。出于这个原因,我经常使用OERN,因为VBA对于一些你无法完全预料到的情况非常敏感。 1 - 错误是否会导致数据损坏。如果是的话。我使用的很多例程只是处理大量记录,导入的数据中可能存在错误,这些错误尚未解决。通常我有很多转换过程会让系统最终清理自己的数据。

2 - 是错误频繁和非关键(即,不是一个键)。如果是的话,这是OERN,否则错误可能是不可预知的,你最终崩溃或不得不编写一堆I-T-E或Select Case逻辑来捕获它。

相关问题