Not every error in your code can be caught during compilation, because some errors depend upon values that won’t be known until the application is actually running. From a purely syntactic point of view, there’s nothing wrong with this:
dim a(4) as integer dim i as integer for i = 1 to 5 a(i) = i next
But the code is doomed anyway, because when it actually runs, the
last time through the
For loop, it will attempt to
a(5)—and there will be no
a(5). If you build your application and run it,
when this code executes, it puts up a dialog (shown in Figure 8-2) and terminates prematurely. Albeit politely
and gently, your application has crashed.
Figure 8-2. A runtime error in the application
If you run the same code in the IDE, the running project still terminates, but things are better in one respect—you learn where in your code this happened. As the running project vanishes, it drops you into the IDE, where a popup window appears below the offending line and describes the error (see Figure 8-3).
Figure 8-3. A runtime error in the IDE
This is an example of a runtime error , technically known as an exception . Most of the time, you’ll probably try to eliminate runtime errors from your program in advance, perhaps with the help of the debugger, which is discussed in the next ...