Instead of using the conditional compilation mechanism of Section 1.11, 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 will be omitted. But if we run it with a
-D
argument to enable
debug.fetch
, the printout will occur:
> 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 at the end of this
chapter, in Section 1.19. My Debug
class also provides the string “debug”. as part of the
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 >
3.15.168.214