# Visual Basic > Visual Basic FAQs >  Classic VB - Why is using the 'End' statement (or VB's "stop" button) a bad idea?

## si_the_geek

One kind of question which often comes up on the forums is about how to close your program, and unfortunately a common reply to this is to recommend something which is easy to write, but can cause big problems:  the "End" statement.

There are several reasons you should avoid End (and the 'stop' button in the VB editor), which I will now explain.

*Why you should never use "End"*
When you want to turn your computer off, do you click on "_Shut down_" (or "_Turn off computer_") as you are supposed to, or do you pull the power cable out of the back?  Using End is very similar to pulling the cable, which I'm hoping you wouldn't do!

The End statement is basically a way of making your program _crash_, but without showing any error messages.  Like any other time a program crashes, you may find that it has done some damage, perhaps enough that you need to reboot the computer, or even so much that you can't use the program (or the files it was working with) ever again.

From VB's help on End:



> Note The End statement stops code execution abruptly, without invoking the Unload, QueryUnload, or Terminate event, or any other Visual Basic code. ...  Object references held by other programs are invalidated. 
> 
> ... For normal termination of a Visual Basic program, you should unload all forms. Your program closes as soon as there are no other programs holding references to objects created from your public class modules and no code executing.


The first half of this quote lists some of the problems with End, but as it doesn't really explain why they are so bad I will give some more detail:

The part "*without invoking the Unload, QueryUnload, or Terminate event*" means that any code you have put into those events will not run.  Typically code you have in those events will be to tidy-up (such as deleting temporary files you made, disconnecting from a database, closing a program you are automating, etc), or to show a message like "_are you sure you want to exit?_" (for an explanation of how to do that, see this article).

Any code you wrote in those events was written for a reason, so why are you stopping it from running?

If you are sub-classing in your program (or any of the references/components you are using do any sub-classing), this means that your program wont tidy up as required, and due to the nature of sub-classing it will crash in a very bad way.  If you are running the code in VB itself, you will almost certainly crash VB too, and so lose any changes you have made to the program since your last save.
The part "*or any other Visual Basic code*" means that any code which is currently running (such as a long-running loop, or code in a Timer) will _suddenly_ stop.. but what was it doing at that time, and what damage will stopping it cause?  

The answers obviously depend on your program and the timing, but just pretend that it was writing a file - that file will now have some data in it, but will not be complete (and the user probably won't know). If the user tries to open that file at some point, they may get an error, or use only _some_ of the data they want (but they will think that it is _all_ of the data).
The part "*Object references held by other programs are invalidated*" means that any other programs that communicate with yours in any way are likely to have an error of some kind.

This includes many things you add to the 'References' of your project (such as ADO/Word/Excel/Crystal Reports/..) and any programs that your controls work with.

What the problems might be depend on what the "_other programs_" are, but include things like a simple error message being shown, perhaps a crash (of just the other program, or even Windows itself), maybe locking files/databases so they cannot be used again until you shut down (and perhaps even permanently), and even corrupting files (this is particularly true of databases which use Jet, such as Access).

As programs get more complex, the chances of using "End" causing damage to your files/memory/etc increase (and that damage may be permanent), so it is best to avoid it - even if your program is 'simple' at the moment!

The second half of the quote (which says what you should do instead of using End) is explained in more detail by the article How should I close my form/program/class?.


*A note about the 'stop' button in the VB editor* 
This is basically the same thing as using End, so should be avoided if possible.  Instead, try to exit your program in the same way that a user would - which also lets you check that any code that runs when the forms/program closes is working properly.

If you are doing any sub-classing (directly, or via References or Components which do it), pressing this almost guarantees that you will crash VB, and lose any work you haven't saved (as explained in the section above).

----------

