Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
However, interactive debuggers that allow you to step through your code and inspect your program's variables and view the
stack trace have been around since the early 1980s. So it surprises me that even after all that time, many programmers still
primarily use print statements to debug their code. As a Java programmer, you are probably all too familiar with the
System.err.println() methods. In fact, most Java programmers I know use a combination of a text editor, the JDK, and
println statements to develop, debug, and deploy their applications.
While print statements can be useful, I have never found them to be very effective. Inspecting hundreds of output lines can be quite overwhelming, and the code itself gets cluttered with numerous lines of debugging statements. Also, if you do not capture the output to a file, you can find yourself scrolling up and down your console window only to discover that you have lost some of the output because your window's buffer size is too small.
That scenario becomes even worse in JSP/servlet development. With standalone applications or applets, you generally know where
the output of
System.err is located -- either in your console window or in the browser's Java console. With JSP and servlets, you can probably find
the output in the JSP/servlet engine's log files, but that isn't always the case. The JSP/servlet engine's error output and
standard output can go to different files. To make matters worse, most JSP/servlet engines allow you to configure/specify
the name of the log files. If an administrator reconfigures the default location of these files, you can waste time trying
to locate the files; and if you don't have permission to access the files, you are out of luck until the problem is fixed.
Experienced developers generally use some sort of a logging/tracing framework that can send all debugging messages to one or more files. In addition, those frameworks can include various debugging levels that can be configured in the application. So for troubleshooting purposes, an application's debugging level can be turned up (like a volume control), and more debugging and/or diagnostic messages can be generated.
Of course, even better alternatives are available in the market today, in the form of new and improved debugging tools. For example, MetaMata's debugging solution allows you to debug JSP code. Traditional Java IDEs such as Visual Café and JBuilder allow you to step through code. In my opinion, Visual Café is one IDE that has finally gotten it right after five years in existence. Visual Café 4.0x loads much faster than its predecessors, and it is also very stable and provides powerful features such as remote EJB and JSP debugging. Those features can almost entirely eliminate the need for print statements -- at least for debugging purposes -- though you still might want to use them for logging.