classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: debug output problem in ObjectInputStream


From: Stuart Ballard
Subject: Re: debug output problem in ObjectInputStream
Date: Tue, 09 Apr 2002 09:57:11 -0400

Sorry for the late response to this thread.

Warren Levy wrote:
> 
> It wasn't so much an issue of it being overridden, as it seemed like
> a much cleaner approach than having separate conditionals and println's
> spread throughout the code.  I found it very helpful when debugging to
> just set a breakpoint for dumpElement; if we get rid of the method and
> sprinkle the code with the conditional and prints, we'll lose that ease
> in debugging.  Having a separate dumpElement method also certainly improved
> readability of the code (at least IMO).  I'm fine though with readability
> and ease of debugging suffering a little bit, if it avoids needless
> processing in the typical case.

Why not get the best of both?

if (Configuration.DEBUG) dumpElement(whatever);

The only check that needs to be outside the dumpElement call is the bit
that's a compiletime constant. As I understand it, that's
Configuration.DEBUG (not sure what "dump" is - I haven't read the code).

The code for dumpElement should also include a test for
Configuration.DEBUG. That way when debugging is off it will compile to
an empty method, saving some code size.

Now the code is readable, you can still set a breakpoint in dumpElement
(as long as debugging is enabled) and nothing at all gets compiled into
the code if debugging is disabled.

This style of code has been my standard debugging practice for ages. I
use a debug method to encapsulate my output, but I only invoke it if
some compiletime-constant is true to indicate that debugging is enabled.

Stuart.

-- 
Stuart Ballard, Programmer
NetReach - Internet Solutions
(215) 283-2300, ext. 126
http://www.netreach.com/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]