按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
shown in Figure 5…1。 When Visual Basic reaches this breakpoint； it goes into debug mode； this
mode is different from application mode—the state it is in before it reaches the breakpoint and
after it leaves the breakpoint。 To leave debug mode； you can press the F5 key to switch to appli
cation mode and continue executing the application； or press Ctrl＋Alt＋Break to stop debugging
and stop executing the application。
Figure 5…1。 Debugging an application with a breakpoint
Running an application in the debugger is useful when tracking down exceptions； as you’ll
see in the next section。
Handling Exceptions
Those who recall the “good old days” of Windows 3。0 and its 16 bits will also remember the
dreaded three…finger salute。 The three…finger salute refers to pressing Ctrl＋Alt＋Delete to reboot
Windows after a program crashed。 You did not have the chance to save your work； you just had
to watch everything go down the drain。
If you missed those puting days； count yourself lucky。 Nowadays； we have mechanisms to
catch unexpected errors and make sure that the program or operating system keeps on processing。
…………………………………………………………Page 140……………………………………………………………
118 CH AP T E R 5 ■ L E A R N IN G AB OU T V I SU A L B AS IC E X C E P TI ON H AN D L IN G
The big deal with modern operating systems and programming environments like the CLR is
that they can stop a single task from disrupting the operation of the CPU。
Catching Exceptions
Recall that in Chapter 2； Visual Basic Express interrupted the flow of the program by catching
the exception generated by a mathematical overflow situation。 This is like your driving teacher
realizing you are making a mistake and pressing hard on the brake； so you don’t hit a tree； person；
or another car。 So； in a sense； you can think of the CLR exception…handling mechanism as the
teacher stepping on the brake when something devastating is about to happen。
Stepping on the brake stops the devastation； but you； as the driver； will get a shock because
of the error that you were about to make。 Likewise； when an exception is triggered； the program
gets a shock。 How you deal with the shock determines the fate of the program。 In the example
of the overflow error in Chapter 2； the shock was captured by the IDE； and thus a friendly； easy
to…understand user interface was presented。
Consider the source code shown in Figure 5…2； which generates an exception。 This is referred
to as throwing an exception。
Class declaration with a
single data member
Class is declared； but
Class MyType
Public DataMember As Integer not instantiated
End Class
Class Tests
Public Sub GeneratesException（）
Dim cls As MyType = Nothing
cls。DataMember = 10
End Sub
Public Sub RunAll（） Data member of the class is assigned even
GeneratesException（） though the class has not been instantiated。
End Sub
This will cause an exception。
End Class
Figure 5…2。 Throwing an exception
If the RunAll（） method were executed； the exception shown in Figure 5…3 would be generated
in Visual Basic Express （use F5 to run the debugger）。
The exception did not cause the operating system or Visual Basic Express to crash； because
Visual Studio’s built…in exception handler caught it。 Visual Studio hit the brake and made sure
that only your program stopped working。
Imagine if Visual Studio were not running。 The generated exception would cause the program
to stop in its tracks； and a messy error message would appear； referencing objects； line numbers；
and the stack。 Most users would have no idea what happened； and be left with a program that
was not working anymore。
…………………………………………………………Page 141……………………………………………………………
CH AP T E R 5 ■ L E AR N IN G AB O U T V I SU A L B AS IC E X CE PT I ON HA N D L IN G 119
Figure 5…3。 An exception generated by a null reference
What you want to do is catch the exception as Visual Studio did。 For example； if you knew
that an exception could occur in RunAll（）； you could modify the code as follows：
Class MyType
Public DataMember As Integer
End Class
Class Tests
Public Sub GeneratesException（）
Dim cls As MyType = Nothing
cls。DataMember = 10
End Sub
Public Sub RunAll（）
Try
GeneratesException（）
Catch exception1 As Exception
End Try
End Sub
End Class
The bolded code is an exception block； which catches an exception and allows you to respond
to it。 In this example； nothing happens after catching the exception。 If you run this program；
Visual Basic will not generate an exception warning； and the program will run without any
problems。 From the perspective of Visual Basic； everything worked and is running OK。
But if you stop and think about it； is everything really OK？ Even though the program
continued to execute； was the program logically correct？ The answer is no； because what the
program did was swallow an exception without doing anything to remedy the problem。 You
should not do such a thing； because it implies sloppy program