2013-03-17 59 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邏輯來捕獲它。