Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Make Your Error Routines Return Data
Does your error routing handle errors without returning data? I’ve created some of these gaffes, with the best intention to get back and flesh them out (see Figure 8).
)
The code in Figure 8 will execute and give the message Completed Creating Northwind database—even though it has failed to create the database because the path is bogus. The error has been handled, so it won’t bubble up, but no information has been gleaned.
Interestingly, if I move the code in CreateDatabases to the Button1_Click event handler instead of calling a routine, the error bubbles up to the operating system even though I still have a skeleton Try/Catch block (see Figure 9).
)
The same thing happens if I remove the Try/Catch block from the CreateDatabases routine—the error bubbles to the runtime (see Figure 10).
)
Actually, this result is preferable if you’re not going to retrieve and display error information from the Catch block. At least some message as to what’s happening will come through. Regrettably, however, the user will be the one to tell you about it.
One last point about structured exception handling: Not all routines require a Try/Catch block. You may prefer to handle the routine from a calling routine. In that case, you wouldn’t have Try/Catch code in the called routine. This is perfectly acceptable.