TheEvil End Statement
Most beginning VB programmers start with very simple, one-form projects. Only a few beginning texts even mention setting the Startup Object to being a Sub Main and not having any forms at all, but perfectly valid VB programs can be built that way. One of the simplest possible VB programs that I have ever seen suggested looks like this:Private Sub main ()
And indeed it does work just fine. But why is that End Statement there? I once asked the author of a book featuring a similar program, and the answer was along the lines of "because itís good for students to get in the habit of cleaning up their programs when done." I could neither agree more with the stated reason, nor less with the method suggested.
My claim: The End Statement is exactly the opposite of proper program cleanup. I frequently espouse this viewpoint in the newsgroups, userís groups and other fora where I discuss VB. Sometimes people tell me that the End Statement "solves a host of other problems" when they are shutting down their application. No, I contend, it does nothing of the sort, but it does cover some up. Sometimes it is even successful at covering up bad program cleanup.
What does the End Statement do? Pretty much the same as the Stop button in the VB IDE. It halts all program execution, and reclaims the memory where it was running. It does not terminate forms, controls, objects, or anything else. It does not release any external allocations, links, databases, or much of anything else that the application might have set up. Most DBMSís recover successfully when a client abruptly disconnects, but thatís just a matter of someone else cleaning up after the VB app.
My claim (#2): The End statement is never necessary. Any properly designed VB application will terminate cleanly without an End Statement. Unload all forms, let all running code procedures terminate, and free up all other allocations, and a VB application will exit properly. Iíve had people bring me projects, insistent that there must be a real need for their End statement, because without it, their application continues to be visible in the Windows Task List. Obviously, something in VB isnít completing properly, because of my complex application, they say. Iím forced to agree, and every time, at least so far, Iíve been able to point to a specific element of their own code that was never properly cleaned up. Perhaps merely an object reference, but sometimes itís actually something like a subclassing pointer or system hook, and theyíve never even made a connection between the inevitable crash that comes some time after they terminate their program with an End. It was some other application that crashed, or the system itself, perhaps hours or even days later - hardly a finger pointing at them Ö or so they think.
How can I avoid the End Statement, they ask, and there are some good answers, but proper program design tops the list. Always set your own object references to Nothing, or be absolutely certain that they will be by the system. When using any API, learn not only what it needs to start up, but what it needs to be properly cleaned up when youíre done. Especially harmful are keyboard hooks, subclassing, and other practices that make alterations in processes other than your own. But those arenít beginner topics, some reply, and I completely agree. Beginners donít generally do any of those things, so in fact beginners canít even fool themselves into thinking they need an End Statement. So why should we teach it to beginners at all? I contend that we should not.
When a beginner starts with VB, and we tell them to use the End statement to "clean up" after their program, I contend that we are not only encouraging a bad habit, but actually telling them something that is simply not true. The End does not "clean up" anything, though it does successfully cover up the most common messy programs.
Whatís the right way for a beginner to cause their program to properly exit? Unload all forms, and let any code procedures exit. Thatís really all it takes. For almost all simple one-form projects, merely unload the form. If there is no code that was actively processing a loop, nothing more is likely to be needed. For somewhat more complex programs, unload all forms, and if thereís a loop of some kind, whether in Sub Main or elsewhere, exit the loop and allow the procedure to complete. The vast majority of beginner and student projects do all these things anyway, the End Statements in them are purely superfluous. So what harm do they do? In those programs Ė none; in those programmers Ė plenty.
My claim (#3): if your program does not exit cleanly without an End Statement, then your program contains a bug or bugs. Take out the end statement, and do whatever testing it takes to clean up whatever you had failed to clean up previously.