ProblemYou want to have debugging statements left in your code enabled at runtime. SolutionUse my Debug class. DiscussionInstead of using the conditional compilation mechanism of Recipe Recipe 1.10, you may want to leave your debugging statements in the code but enable them only at runtime when a problem surfaces. This is a good technique for all but the most compute-intensive applications, because the overhead of a simple if statement is not all that great. Let's combine the flexibility of runtime checking with the simple if statement to debug a hypothetical fetch( ) method (part of Fetch.java): String name = "poem"; if (System.getProperty("debug.fetch") != null) { System.err.println("Fetching " + name); } value = fetch(name); Then, we can compile and run this normally and the debugging statement is omitted. But if we run it with a -D argument to enable debug.fetch, the printout occurs: > java Fetch # See? No output > java -Ddebug.fetch Fetch Fetching poem > Of course this kind of if statement is tedious to write in large quantities, so I have encapsulated it into a Debug class, which is part of my com.darwinsys.util package. Debug.java appears in full in Recipe 1.17 at the end of this chapter. My Debug class also provides the string "debug." as part of the argument to System.getProperty( ) , so we can simplify the previous Fetch example as follows (code in FetchDebug.java): String name = "poem", value; Fetch f = new Fetch( ); Debug.println("fetch", "Fetching " + name); value = f.fetch(name); Running it behaves identically to the original Fetch: > java FetchDebug # again, no output > java -Ddebug.fetch FetchDebug Fetching poem > See AlsoSome more comprehensive and flexible "debug printout" mechanisms including ones that can log across a network connection are covered in Recipes Recipe 17.7, Recipe 17.8, and Recipe 17.9. |