近一年來受工作的關系看其他程序員的代碼的機會變多了，學習了不少東西，但同時也發現很多問題，其中我遇到的最多的就是對錯誤的處理態度。
1） 從不攔截錯誤；
這可能是最原始且是最不好的行為，他們總是認為自己的程序肯定100%不會出現問題，因為他們堅信自己的代碼考慮了一切可能的情況，這種理解我認為是非常危險的，翻翻你的代碼，看看是否考慮了以下常見的情況：
l 在只允許輸入數字的文本框裡你攔截了鍵盤事件，但用戶用右鍵粘貼了文本後你的程序正常嗎？
l 設置了Locked屬性的文本框用戶一樣可以粘貼，你的程序出問題了嗎？
l 磁盤空間不足、目錄只讀、沒有權限、目錄名中有小數點、系統采用了短日期甚至不標准的格式；
l 明明事先檢查了磁盤空間足夠，可用戶偏使用了什麼磁盤配額，還是磁盤空間不足；
l 用戶在你一段長時間的操作工程中等的不耐煩強行關機後重新運行你的這段程序；
l 你是否相信Access數據庫或SQL Server數據庫設置字段不能為空，但數據庫就會莫名其妙的有NULL值在裡面；
你所想象不到的情況太多了，所以說你永遠不可能考慮所有的情況。
2） 總是攔截錯誤；
這種情況和第一種情況恰恰相反，他會不厭其煩的在每個過程中都添加On Error Goto ，然後出錯的話報一個MsgBox框出來，我相信倆年以上五年以下工作經驗99%的VB程序員基本上都是這麼做的，也許馬上就有人立即站起來說：你剛才還說不可能考慮每一種情況，所以要攔錯，為什麼馬上反悔了呢？這裡我想提出我的第一個重要觀點：
盡量不要封殺任何的底層錯誤。
我們假設有4個過程A,B,C,D，其中A調用了B，B有調用了C，C又調用了D，如果我們在每個子過程中都攔截了錯誤，那麼如果D發生了錯誤，程序將報告發生一個錯誤，顯然這時D退出後，C其後的代碼就不應該執行了，似乎他現在唯一的辦法只有通過D返回False來表示失敗，他才知道底層失敗了，不能繼續執行了，同樣的道理C和B都要返回False來取消任務。
天啦，這豈不是要沒有過程都要寫成返回True和False了，看看你的程序，這可能嗎？而且你將遇到一個非常尴尬的局面，你調用任何一個函數都要這樣調用：
If B = False Then
A = False
Exit Sub
End If
我想你肯定覺得不爽，不僅如此你還有一個致命的問題：最上層的程序（注意是程序而不是用戶）根本不知道底層什麼地方失敗了，什麼原因失敗了，他唯一知道了事就是失敗了！啊，真慘。
既然這樣我們回頭看看底層不攔截錯誤的情況：
Public Sub A()
On Error Goto ErrorHandler
B()
'Do some thing
Exit Sub
ErrorHandler:
MsgBox(Err.Description)
End Sub
Public Sub B()
'Do some thing
