没有错误的程序，你这种情况应该还是代码上存在问题，曾经有位大师
不想信他的一们读都说的程序在有问题，但是当他放下自尊，准备测试这个程序才发现的确有问题。
原文如下：
Paul found the one currency value in the project and changed its type from Currency to Double. The bug disappeared. He sent me mail describing the problem. I replied that his eyes were deceiving him and that he could not have gotten that message. If he wanted to be sure there were no floating- or fixed-point variables in the program, he could remove the BugAssert statements from the Notify code and remove Debug.bas from the project. Paul replied that with the type changed from Currency to Double, he now got the error after running Notify for four to five hours. He then removed Debug.bas and all the BugAsserts and the bug went away completely-even after runs of 17 hours. Well, this is not the kind of bug any programmer likes to think about. What was I going to do about it? Run Notify for four hours until the bug appeared for me? What would the error message tell me that I hadn''t already heard and disbelieved? So I did what any self-respecting programmer would do. I forgot all about it. Or at least I tried. Then several months later I left the VB6 version of Notify running overnight for a completely different reason. When I returned to my computer, there it was-the floating-point error I had doubted. 至今这位大师还不知道问题出在哪儿，他只是删除了那个Debug.bas.我想这还不是解决问题的方式，你可以试试给你的程序加上行号，使自己
知道程序到底错在哪儿。
Line numbers!? Yup, just like those used in “real” Basic. Bear with me here—I’ll convince you!In older versions of Basic, line numbers were often used as “jump targets” as well as simply being mandatory. A jump target is a line number used with a GoTo, such as GoTo 2000. The 2000 identifies the start of a block of code to execute next. After GoTo came GoSub (and Return). Now you had a “Basic subroutine,” albeit one with a strange name: GoSub 2000. You can think of the (line) number almost as an address (just as in C). These days, of course, Basic is Visual Basic and we use symbolic names for labeling such jump targets (real subroutines, just like those in C and other programming languages). Line numbers have become a peculiarity designed to allow nothing more than some level of backward compatibility with some other version of Basic.Or then again, maybe not. In Visual Basic, Erl, a Visual Basic (undocumented in Visual Basic 4 and 5 but present in all versions of Visual Basic thus far) “global variable,” gives you access to the line number of any erroring line of code. So by using line numbers and by using Erl in your error handlers, you can determine which line of code erred—wow! What happens to Erl if you don’t use line numbers? Easy—it will always be 0.Of course, you won’t want to start typing line numbers in by hand. You need some automation. At TMS, we add line numbers to our code using an internal tool we originally developed for working with Visual Basic 2. It now works as an add-in under Visual Basic 5. There are tools on the et that can do the same for your code.At TMS, we don’t work with line numbers in our source code, however. We add them only when we’re doing a ship build—that is, when we want to ship a binary to, say, beta testers or to manufacturing for an impending release. We use our internal tool to build a new version of the code, complete with line numbers, and then we make an executable from that. We store the line numbered source code in our source control system and ship the executable. We cross-reference the EXE version number (the Auto Increment option is just great here) to the source code stored in the source control system. Every time we do a new build for shipping, we create a new subproject whose name is the version number of the build and store the line numbered source code in it along with a copy of the binary image. If an error report comes in, we can easily refer back to the source code to find the erroring line (very, very easy if you’re using Microsoft Visual SourceSafe). Typically, the error report will contain details of the module, routine, and line number of the error.Listing 1-2 is a typical Click event, line numbers and all.Listing 1-2Generic Click event with line numbersPrivate Sub Command1_Click()
'' =============================================================
'' Module Type : Form
'' Module Name : Form1
'' Object : Command1
'' Proc Type : Sub
'' Proc Name : Click
'' Scope : Private
'' Author :
'' Date : 01/01/97 00:00
''
'' History : 01/01/97 00:00: Peter J. Morris : Original Code.
'' ============================================================='' Set up general error handler.
On Error GoTo Error_In_Command1_Click:1 Dim sErrorDescription As String2 Const sProcSig = MODULE_NAME & "Command1_Click" '' ========== Body Code Starts ==========3 Debug.Print bDriveExists("") '' ========== Body Code Ends ==========4 Exit Sub'' Error handler
Error_In_Command1_Click:5 With Err
6 sErrorDescription = "Error ''" & .Number & " " & _
.Description & "'' occurred in " & sProcSig & _
IIf(Erl <> 0, " at line " & CStr(Erl) & ".", ".")
7 End With8 Select Case MsgBox(sErrorDescription, _
vbAbortRetryIgnore, _
App.Title & " Error") Case vbAbort
9 Resume Exit_Command1_Click:
10 Case vbRetry
11 Resume
12 Case vbIgnore
13 Resume Next
14 Case Else
15 End16 End SelectExit_Command1_Click:End Sub
Notice in Listing 1-2 that sProcSig is made up of the module name (Form1) and the routine name (Command1_Click). Notice also that the error handler examines Erl to “see” whether line numbers have been used. Figure 1-1 shows what’s typically displayed when an error occurs using this kind of scheme.Figure 1-1 Error and line number informationOf course, the actual code that makes up the error handler is entirely up to you. If you use this scheme, I recommend you have a module-level constant to hold your module name and use a routine-level constant to hold the routine name plus the module name:Module Declaration Section
Private Const MODULE_NAME As String = "Form1."
Command1_Click Event
Const sProcSig As String = MODULE_NAME & "Command1_Click"这样你就知道错在哪儿了。
不想信他的一们读都说的程序在有问题，但是当他放下自尊，准备测试这个程序才发现的确有问题。
原文如下：
Paul found the one currency value in the project and changed its type from Currency to Double. The bug disappeared. He sent me mail describing the problem. I replied that his eyes were deceiving him and that he could not have gotten that message. If he wanted to be sure there were no floating- or fixed-point variables in the program, he could remove the BugAssert statements from the Notify code and remove Debug.bas from the project. Paul replied that with the type changed from Currency to Double, he now got the error after running Notify for four to five hours. He then removed Debug.bas and all the BugAsserts and the bug went away completely-even after runs of 17 hours. Well, this is not the kind of bug any programmer likes to think about. What was I going to do about it? Run Notify for four hours until the bug appeared for me? What would the error message tell me that I hadn''t already heard and disbelieved? So I did what any self-respecting programmer would do. I forgot all about it. Or at least I tried. Then several months later I left the VB6 version of Notify running overnight for a completely different reason. When I returned to my computer, there it was-the floating-point error I had doubted. 至今这位大师还不知道问题出在哪儿，他只是删除了那个Debug.bas.我想这还不是解决问题的方式，你可以试试给你的程序加上行号，使自己
知道程序到底错在哪儿。
Line numbers!? Yup, just like those used in “real” Basic. Bear with me here—I’ll convince you!In older versions of Basic, line numbers were often used as “jump targets” as well as simply being mandatory. A jump target is a line number used with a GoTo, such as GoTo 2000. The 2000 identifies the start of a block of code to execute next. After GoTo came GoSub (and Return). Now you had a “Basic subroutine,” albeit one with a strange name: GoSub 2000. You can think of the (line) number almost as an address (just as in C). These days, of course, Basic is Visual Basic and we use symbolic names for labeling such jump targets (real subroutines, just like those in C and other programming languages). Line numbers have become a peculiarity designed to allow nothing more than some level of backward compatibility with some other version of Basic.Or then again, maybe not. In Visual Basic, Erl, a Visual Basic (undocumented in Visual Basic 4 and 5 but present in all versions of Visual Basic thus far) “global variable,” gives you access to the line number of any erroring line of code. So by using line numbers and by using Erl in your error handlers, you can determine which line of code erred—wow! What happens to Erl if you don’t use line numbers? Easy—it will always be 0.Of course, you won’t want to start typing line numbers in by hand. You need some automation. At TMS, we add line numbers to our code using an internal tool we originally developed for working with Visual Basic 2. It now works as an add-in under Visual Basic 5. There are tools on the et that can do the same for your code.At TMS, we don’t work with line numbers in our source code, however. We add them only when we’re doing a ship build—that is, when we want to ship a binary to, say, beta testers or to manufacturing for an impending release. We use our internal tool to build a new version of the code, complete with line numbers, and then we make an executable from that. We store the line numbered source code in our source control system and ship the executable. We cross-reference the EXE version number (the Auto Increment option is just great here) to the source code stored in the source control system. Every time we do a new build for shipping, we create a new subproject whose name is the version number of the build and store the line numbered source code in it along with a copy of the binary image. If an error report comes in, we can easily refer back to the source code to find the erroring line (very, very easy if you’re using Microsoft Visual SourceSafe). Typically, the error report will contain details of the module, routine, and line number of the error.Listing 1-2 is a typical Click event, line numbers and all.Listing 1-2Generic Click event with line numbersPrivate Sub Command1_Click()
'' =============================================================
'' Module Type : Form
'' Module Name : Form1
'' Object : Command1
'' Proc Type : Sub
'' Proc Name : Click
'' Scope : Private
'' Author :
'' Date : 01/01/97 00:00
''
'' History : 01/01/97 00:00: Peter J. Morris : Original Code.
'' ============================================================='' Set up general error handler.
On Error GoTo Error_In_Command1_Click:1 Dim sErrorDescription As String2 Const sProcSig = MODULE_NAME & "Command1_Click" '' ========== Body Code Starts ==========3 Debug.Print bDriveExists("") '' ========== Body Code Ends ==========4 Exit Sub'' Error handler
Error_In_Command1_Click:5 With Err
6 sErrorDescription = "Error ''" & .Number & " " & _
.Description & "'' occurred in " & sProcSig & _
IIf(Erl <> 0, " at line " & CStr(Erl) & ".", ".")
7 End With8 Select Case MsgBox(sErrorDescription, _
vbAbortRetryIgnore, _
App.Title & " Error") Case vbAbort
9 Resume Exit_Command1_Click:
10 Case vbRetry
11 Resume
12 Case vbIgnore
13 Resume Next
14 Case Else
15 End16 End SelectExit_Command1_Click:End Sub
Notice in Listing 1-2 that sProcSig is made up of the module name (Form1) and the routine name (Command1_Click). Notice also that the error handler examines Erl to “see” whether line numbers have been used. Figure 1-1 shows what’s typically displayed when an error occurs using this kind of scheme.Figure 1-1 Error and line number informationOf course, the actual code that makes up the error handler is entirely up to you. If you use this scheme, I recommend you have a module-level constant to hold your module name and use a routine-level constant to hold the routine name plus the module name:Module Declaration Section
Private Const MODULE_NAME As String = "Form1."
Command1_Click Event
Const sProcSig As String = MODULE_NAME & "Command1_Click"这样你就知道错在哪儿了。
我有一个VB的插件，可以直接在原有的代码中添加行号和包含行号的错误处理程序，如果你要，留EMAIL。