I've written already about debugging a server-side application within an IDE as a very useful technique, but I want to point out that it should absolutely not be the only one debugging facility that a developer should use. In general, the writer of server-side code MUST place logging calls that trace the execution and allow the consumer of the code to configure the logging level.
I say must and I really mean it, there are cases in which using a debugger is not practical (a library supplied in binary-only form) or not even possible (a bug in a production environment, accessible only to the operations people): imagine that you turn on all the debug flags and there is no line of logging output, what can you do now? Do you try to attach a debugger to a production JVM? I can hear the operations people rolling on the floor laughing at you...
I consider code without logging as untested; stepping inside it once with a debugger doesn't count. If the code doesn't log anything it means it has not been put to test into "real world" conditions, and I do not want to be a guinea pig again, I've had my share of crap code to deal with and that's enough. My tolerance level has dropped to zero.
I say must and I really mean it, there are cases in which using a debugger is not practical (a library supplied in binary-only form) or not even possible (a bug in a production environment, accessible only to the operations people): imagine that you turn on all the debug flags and there is no line of logging output, what can you do now? Do you try to attach a debugger to a production JVM? I can hear the operations people rolling on the floor laughing at you...
I consider code without logging as untested; stepping inside it once with a debugger doesn't count. If the code doesn't log anything it means it has not been put to test into "real world" conditions, and I do not want to be a guinea pig again, I've had my share of crap code to deal with and that's enough. My tolerance level has dropped to zero.