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/ _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
