If your program doesn't behave as expected then there are a number of steps that you can take to resolve the problem. The most important thing is to try to identify the source of the error BEFORE you go ahead and start hacking the code any further. If you try to get the program to work by changing things in an unplanned manner then you'll make it worse. Not only will you not understand the cause of the problem but you may then not be able to work out how your code "evolved" though unplanned changes.
If your program will compile but still does not behave as intended then you need to figure out the reasons for the problem. At this stage there may be one or two obvious things to try. For example, if a Component does not appear on the screen then you may have forgotten to show() it or it may have a size of (0,0) or it may have been postioned off the screen itself. Alternatively, if a Component does not respond to an input event then you may not have written an approrpiate listener method for its class. Before altering your code, you should satisfy yourself that your hypothesis would account for the behaviour that you observe.
Hint: at this stage, I usually try to get a friend to check things. If I can convince them that my hypothesis is correct only then will I fgo ahead and re-write the code.
Sometimes, the behaviour of a program is so complex that it makes more sense to write a small program simply to test out your hypothesis. These programs can be used in the documentation for your final product - they are evidence of testing. This simplification process helps to ensure that you understand the cause of your problem rather than becoming obsessed by the various symptoms that you observe by hacking away at the full implementation.
Debug statements simply print out information that can be used to trace the causes of a problem. They are intended for programmers, they are not intended for the user of an application. It, therefore, follows that they should be switched on during development but MUST be turned off in the final product. A simple means of achieving this is through the use of boolean constants that can be set to true if the statements are to be printed or false if they are not to be shown. For example, a very crude form of DEBUG statement might be implemented as follows if(DEBUG==true) System.out.println("Got to here..."); Remember that in some browsers you will have to explicitly select the Java Console in order to view this output (Hint: it's usually under the options menu).
Please leave debug statements in your programs - if someone else wants to use your code after you have finished then they can help them to understand the way that your program works.
If you really cant get you program to work then ask your friends, demonstrators or tutor for help. This is valid even in assessed exercises, providing that you acknowledge the help in a comment beside the code - after all they may introduce further bugs and it is good practice to provide a reference to the author of each part of your program.
Finally, if your program does not work as intended the you MUST state this in the documentation. You must also provide an account of any tests that you have conducted to explore the problem as well as a brief description of the final working hypothesis that might explain the source of the bug. This will help anyone who fllows after you to improve upon your code and possibly remove the problem.